[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