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 _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
