On Feb 5, 2012, at 10:25 AM, Manish Yadav wrote: > Hi Michael, Robin, > > thanks for input. i was thinking if i am not implementing dtls heartbeat in > that scenario, how could client detect if server is still getting the > messages (assuming the server deleted inactive session after sometime or > server got reloaded), is there any mechanism that could help here? > > i see > http://tools.ietf.org/html/draft-mentz-ipfix-dtls-recommendations-02#section-3.1, > which talks about similar problem (section3) and possible solution. You need a mechanism in the application protocol. If you don't have that, using the heartbeats is (from my perspective) the next option. Please note that it is part of OpenSSL 1.0.1 (currently in beta2) and the corresponding RFC will be out soon (matter of days, I guess). If you don't want to use the heartbeats, you can only renegotiate the DTLS session to see if the peer is still there. Please note that uses more resources than the heartbeat stuff and it might affect the transfer of user messages.
Best regards Michael > > thanks, > manish > > On Mon, Jan 30, 2012 at 1:10 PM, Robin Seggelmann <seggelm...@fh-muenster.de> > wrote: > On Jan 25, 2012, at 5:16 PM, Michael Tuexen wrote: > > > On Jan 25, 2012, at 2:21 PM, Manish Yadav wrote: > > > >> Hi Michael, > >> > >> thanks for quick response. i had one more question, is it possible to do > >> decoupling of ssl object and socket fd to avoid rehandshake? (i am > >> thinking to create socketfd only for active clients, if it is inactive for > >> sometime then close the connection/socket and for inactive clients keep > >> the ssl object cached, whenever inactive clients send data create new fd > >> and associate with old ssl object, similar to > >> http://net-snmp.sourceforge.net/dev/agent/snmpDTLSUDPDomain_8c_source.html). > >> is it possible? > > If you make sure that you don't send anything locally... > > Why not close the DTLS connection after some time and let the client do a > > new connect. You can cache the session > > and the client can use session resumption. > >> > >> if i look at DTLSv1_listen, i am thinking i can not distinguish between > >> active/inactive client? is it possible based on error value from > >> DTLSv1_listen to tell if i received hello message or invalid message or > >> invalid hello message/wrong cookie. > > I don't think so. Robin? > > ClientHello messages are processed, so when the message or its attached > cookie is invalid, an error will be returned. All other messages will be > silently discarded and DTLSv1_listen() will not return, but simply wait for > the next message. > > I'd also recommend session resumption for inactive clients. > > Best regards > Robin > > > >> thanks, > >> manish > >> > >> On Wed, Jan 25, 2012 at 3:24 PM, Michael Tuexen > >> <michael.tue...@lurchi.franken.de> wrote: > >> On Jan 25, 2012, at 7:08 AM, Manish Yadav wrote: > >> > >>> Hi all, > >>> > >>> could you please confirm if dtls timers are implemented at client side > >>> only and not on server side (only client retries/attempts to establish > >>> connection) or why they should be implemented on server side also. > >> You need timers on the server side also. However, > >> DTLSv1_get_timeout/DTLSv1_handle_timeout is only necessary if you use > >> select. > >>> > >>> > >>> after looking at : http://crypto.stanford.edu/~nagendra/papers/dtls.pdf > >>> > >>> i understood that i need to call DTLSv1_get_timeout/DTLSv1_handle_timeout > >>> incase of non-blocking socket. but after looking at example available on > >>> net "dtls_udp_echo2.c", i see only client side take care of this. i feel > >>> only client side should try to reconnect, why server should try to resend > >>> message to client. > >> Not sure about dtls_udp_echo2.c. You might want to take a look at the > >> examples available at > >> http://sctp.fh-muenster.de/dtls-samples.html > >>> > >>> please share if you know any example on this. > >> Maybe Robin has more examples... > >> > >> Best regards > >> Michael > >>> > >>> thanks, > >>> manish > >>> > >>> > >> > >> ______________________________________________________________________ > >> OpenSSL Project http://www.openssl.org > >> Development Mailing List openssl-dev@openssl.org > >> Automated List Manager majord...@openssl.org > >> > > > > ______________________________________________________________________ > > OpenSSL Project http://www.openssl.org > > Development Mailing List openssl-dev@openssl.org > > Automated List Manager majord...@openssl.org > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > Development Mailing List openssl-dev@openssl.org > Automated List Manager majord...@openssl.org > ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
