[Development] Multiclient UDP server
Thiago Macieira
thiago.macieira at intel.com
Wed Aug 23 17:30:11 CEST 2017
On Wednesday, 23 August 2017 02:32:11 PDT Samuel Stirtzel via Development
wrote:
> Yes connect()ing the new socket is the only sane way.
> The old socket could recvfrom() the data and forward it until the new
> socket takes over.
>
> There still will be a time window where a race condition could result
> in duplicated datagrams.
> However, according to rfc8085 UDP based protocols should be resilient
> to datagram duplication.
> Both DTLS and CoAP, just for the sake of an example, can handle
> duplicated datagrams gracefully.
Indeed, I was considering that connect() is the only sane way. It will allow
us to use getsockopt(IP_MTU) to get the path MTU, in addition to getting the
ICMP errors.
The only problem is that "forward until the new socket takes over": that means
the original socket needs to keep a link to the other socket. Otherwise, once
it sees that retransmission that was already queued, it would conclude it's a
new request and would create a new DTLS session object to handle it.
There are two ways to do that:
1) the obvious: just keep a list of all sessions (address 4-tuple) and a
pointer to the session object that will handle the QNetworkDatagram that may
be duplicated.
2) the buffer-draining solution: instead of starting the handling immediately
for each datagram solution, it can ensure that it drained the queue after the
connect() calls. That way, we know there are no more duplicates.
I like #2, but I need to implement it to see if there are any timing problems.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
More information about the Development
mailing list