Ah, that sounds like a very sensible approach. Worst case, you have an optimization issue that can be fixed at a later time. I like it. Thanks Joel.
Tom On Fri, Feb 15, 2013 at 9:43 AM, Joel Dice <joel.d...@gmail.com> wrote: > On Thu, 14 Feb 2013, Tom Cocagne wrote: > >> Thanks for the quick reply Joe. I am definitely interested in seeing your >> example, I've been unable to find many DTLS examples at all and certainly >> none that use an alternative transport mechanism. >> >> Also, have you taken into account the timer for dropped session >> initialization messages? I'm guessing that needs to be manually polled and >> re-sent but exactly how to do that didn't leap out at me from the API. > > > I've written an abstraction that provides datagram send and receive > functionality with optional DTLS support. Since the application already > understands that packets may be dropped arbitrarily, it is expected to > either resend critical packets periodically or send a steady stream of new > data in the hope that some of it will make it to its destination. In other > words, the application promises to keep sending data and my abstraction > promises that eventually some of that data will be delivered (assuming the > network is at least partially functional). > > With that in mind, my implementation uses every send event to check the > status of the DTLS handshake. If it has completed successfully, then great, > we do an SSL_write to our memory BIO and pass the ciphertext to whatever > passes for our network layer. If it has not yet completed successfully, we > simply discard the application's packet and then consult a timer to see how > long it's been since we started the handshake. If it's been "too long" > (based on the backoff scheme recommended in the DTLS spec), we create a new > SSL instance and start over, resetting the timer. > > The disadvantage of this approach is that it starts over from scratch even > if some progress has been made in the handshake which can be salvaged with a > resend. However, I haven't take the time to see if there's some way to ask > OpenSSL to reset back to an earlier state due to a (presumed) lost packet or > if it would be necessary to keep my own copy of the last handshake packet > sent and resend it myself. > > I hope that helps. > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-users@openssl.org > Automated List Manager majord...@openssl.org ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
