Hi Nilesh,
You're right, DTLSv1_handle_timeout() should indeed return -1 in case of an
error because of too many retransmissions. Thanks for the report. I have
submitted a patch (#2543), which is also available on our website
sctp.fh-muenster.de.
Concerning heartbeats, the behavior should be the same as with handshake
timeouts. With the patch, DTLSv1_handle_timeout() also returns -1 in case there
have been too many retransmissions of heartbeat requests.
Best regards,
Robin
On Jun 18, 2011, at 2:34 AM, Nilesh Vaghela wrote:
> Hi,
>
> I am using DTLS in non-blocking mode using select.
>
> There are two parts :
>
> PART I: DURING HANDSHAKE :
>
> As recommended I use DTLSv1_get_timeout and DTLS_handle_timeout when I get
> WANT_READ/WANT_WRITE from all the four calls (SSL_connect, accept, read and
> write).
>
> I treat WANT_READ/WANT_WRITE as IN_PROGRESS.
>
> When I get back IN_PROGRESS, I call DTLSv1_get_timeout and if it returns
> non-zero value, I manage the timer and
> when it is expired then I call DTLS_handle_timeout. This triggers
> retransmission of the last SSL protocol packet.
>
> My question is, how long this should continue before which we declare that
> peer is dead ? Is there any state that gets set in SSL
> layer which triggers some activity on socket so that application knows that
> now it should not retry. I looked at the code of
> dtls1_handle_timeout and it returns 0 for both the cases.
>
> TIMER NOT EXPIRED ---->
> /* if no timer is expired, don't do anything */
> if (!dtls1_is_timer_expired(s))
> {
> return 0;
> }
> ENOUGH ALERTS SENT --->
>
> state->timeout.num_alerts++;
> if ( state->timeout.num_alerts > DTLS1_TMO_ALERT_COUNT)
> {
> /* fail the connection, enough alerts have been sent */
> SSLerr(SSL_F_DTLS1_HANDLE_TIMEOUT,SSL_R_READ_TIMEOUT_EXPIRED);
> return 0;
> }
> WHEN IT RETRANSMITS THEN it returns 1 (as derived from
> dtls1_retransmit_buffered_messages()).
>
> It seems like it should return th ecode other than 0 when it execceds the
> DTLS1_TMO_ALERT_COUNT
> so that application knows that SSL is not going to retry.
>
> So question how else does application know that SSL is giving up now and
> application is supposed to close the connection
> and do application level retry or declare it dead for some time.
>
> I think there is no indication from the library that SSL is giving up as
> after 12 attempts(DTLS1_TMO_ALERT_COUNT)
> it does give up.
>
> PART 2: AFTER HANDSHAKE:
> Once the connection is established, we still need to check the health of the
> peer and check whether it is alive.
> For this we applied the heartbeat patch in 1.0.0d and used
> DTLS_send_heartbeat() function.
>
> Here again the same problem.
>
> Again, I understand that we need to take help of get_timeout and
> handle_timeout functions to retransmit the heartbeat packet.
> But there is no indication from the library that
> 1. heartbeat successful OR
> 2. SSL library will no more send the heartbeat as it made enough attempts OR
> 3. will it indefinitely send the heartbeat and application needs to decide
> and stop sending and declare the connection as dead.
>
> Some guidance will be appreciated.
>
> --Nilesh.
>
>
>
>
>
> --
> [email protected]
> Systems Architect
> Stratacache Inc. (Santa Clara Office)
> O: 408-844-9810(2110)
> M: 408-202-5401
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [email protected]
