DTLS and UDP servers
- Date: Fri, 11 Jan 2019 09:19:44 -0500
- From: bnv@xxxxxxxxx
- Subject: DTLS and UDP servers
[Due to list volume, this address is not subscribed. Please CC with any replies]
Standard practice when using DTLS on a UDP server is to bind and connect a new socket upon receipt of a valid ClientHello on the listener socket. SO_REUSEPORT is required to ensure new sockets can bind to the same port as the listener socket.
This works because the listener socket will see nothing but ClientHello messages, and clients will block on a ServerHello message which is sent after the new connected socket is created.
However, there is a window of opportunity between the bind and connect calls, where the new socket temporarily takes over the port from the listener socket. Ingress ClientHello messages will get delivered to the queue of the new socket within this window. The result is that authentication fails for the new client, and isn't begun for the other clients whose ClientHello messages were diverted.
Arguably, this is UDP so clients should not expect reliability and simply try again.However, this issue is addressable if a mechanism existed to bind and connect simultaneously. Is it feasible?
Note: This would benefit the unsecured UDP server case as well, where it is desired to move a new "session" off the listener descriptor to its own for better scaling. SO_REUSEPORT addresses this to a degree, but is modeled on multiple server processes rather than multiple threads within a single server process.
- Prev by Date: [PATCH 4.9 09/63] scsi: bnx2fc: Fix NULL dereference in error handling
- Next by Date: [PATCH 4.9 05/63] Input: restore EV_ABS ABS_RESERVED
- Previous by thread: [PATCH 7/9] videobuf2/videobuf2-dma-sg.c: Convert to use vm_insert_range_buggy
- Next by thread: [PATCH v5 1/7] nfc: pn533: i2c: "pn532" as dt compatible string