Hi, You can try to use memory BIO pair and call SSL_do_handshake whenever you want and as often as you need, not relying on DTLSv1_get_timeout. Negotiation is finished as soon as SSL_renegotiate_pending returns zero and handshake error is SSL_ERROR_NONE.
Of course, in this case you'll need your own asynchronous timer code and datagram socket code. Regards, Dmitry Sobinov On Wed, Dec 3, 2014 at 11:14 AM, John Lane Schultz < jschu...@spreadconcepts.com> wrote: > I’m using OpenSSL’s DTLS implementation to protect communication over a > soft real time, nearly reliable, out of order higher level protocol. Our > protocol needs to function with low latency even in high loss environments > (e.g. - up to 10% loss). > > I think I'm running into an issue where the redundancy mechanism in > OpenSSL’s DTLS handshake is way too slow and unaggressive for our use in > the face of loss. I believe the OpenSSL client starts with a 1 second > retransmit timer for each flight of the handshake that it doubles each time > it needs to retransmit a flight and none of this is tunable. > > I need a way to control the DTLS handshake retransmission mechanism, even > if it means altering the OpenSSL code directly and compiling against my own > fork, so that it is tunable and much more aggressive. Can anyone advise me > on the particulars of the best way to implement such a change? > > The particular timeouts that OpenSSL chose for its DTLS handshake will not > be suitable for all application needs and I think some other applications > that use DTLS will also need this capability. So, such a change might have > a place in the mainline too. > > Cheers! > > ----- > John Lane Schultz > Spread Concepts LLC > Cell: 443 838 2200 > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-users@openssl.org > Automated List Manager majord...@openssl.org > -- --- Dmitry Sobinov AddLive.com Live video and voice for your application
