Hi Peter, Thank you for your response, that makes sense.
I am also curious, when calling DTLSTransport.Receive(byte[] buffer, int offset, int len, int waitMilliseconds), is there any way to know how long an application level message is? I, obviously, know how long the incoming encrypted DTLS message is, but it contains DTLS headers and may be compressed. I guess, one way is simply to scan the buffer and truncate when I can only see zero bytes. Am I missing something? Also, do you have any guidance regarding the wait parameter? So far, 30 milliseconds seem to work for me. Thanks again! Andriy On 6 May 2015 at 21:09, Peter Dettman <peter.dett...@bouncycastle.org> wrote: > 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 > > -- Andriy Baranskyy Frozen Mountain Software 604-227-6244 800-517-0862 (Toll-Free) www.frozenmountain.com
