Hi Peter, My apologies, please ignore this message. I've figured this out: can get the size of application data message by looking at the return value on the receive.
Andriy On 4 June 2015 at 17:13, Andriy Baranskyy <[email protected]> wrote: > 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 <[email protected]> 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 -- Andriy Baranskyy Frozen Mountain Software 604-227-6244 800-517-0862 (Toll-Free) www.frozenmountain.com
