Hi Andriy,
The way things stand, it is by design that the server (application code)
is expected to begin polling for incoming packets
(DatagramTransport.Receive) after the handshake "completes"
(DTLSServerProtocol.Accept(...) returns), and any retransmits of the
Finished message are handled as part of the Receive call. We do not
create any threads here (or, in general, throughout the codebase). Note
that the server can't be sure the client has received the Finished
message until it sees the first application data from the client arrive.
Even in a situation where the client is not intended to send application
data, polling Receive is needed to drive receipt of alerts, including
any close_notify alert.
We're open to suggestions for improving the DTLS API of course, so let
us know if there's something about your use case that doesn't fit well
with the above.
Regards,
Pete Dettman
On 1/05/2015 12:00 pm, Andriy Baranskyy wrote:
Hi everyone,
I have an issue with the C# implementation. In the DTLS handshake,
the last flight from the server to the client must contain Finished
message. Imagine that this message is lost. In this case, under RFC
6347, client, who never receives the Finished message from server,
will send its messages again. In response, server must re-transmit
Finished message (despite being in the FINISHED state).
It seems as though, when server reaches FINISHED state, it stops
triggering public int Receive(byte[] buf, int off, int len, int
waitMillis) method. Thus, it is not receiving the repeated requests
from the client and never responds to them (with the retransmit of the
Finished message). However, if I trigger it programmatically, then the
server retransmits its last flight. Is there something I could be
missing. Perhaps, you are running an internal thread that exits when
the server reaches Finished state?
Thanks in advance and hope this is not too confusing!
Andriy
