DTLS in gnutls

[Nikos Mavrogiannopoulos]

On Mon, Mar 14, 2011 at 10:44 PM, Jonathan Bastien-Filiatrault
<joe at x2a.org> wrote:

>> called in DTLS. Now I emulate the synchronous behavior
>> of gnutls_handshake() by waiting for few seconds for
>> possible retransmissions by peer, and this has the
>> disadvantage of gnutls_handshake() taking a fixed amount
>> of seconds irrespective of calculations, but requires
>> no semantic changes in the rest of the functions
>> (such as gnutls_record_recv()).
>
> This is a good starting point. However, as you must be aware, this adds
> latency for the blocking case and is a Really Bad Idea in the async case.

Indeed.

> The asynchronous case can be solved simply: require applications to
> monitor the receive side even if they don't read after
> gnutls_handshake() and call gnutls_record_recv() when this happens. This
> assumes that you keep the last flight buffered neatly somewhere, ready
> to send, for a while after gnutls_handshake().
> Example sequence of events:
> - Bunch of writes
> - Event dispatch
> - Bunch of writes
> - Event dispatch
> - Retransmit receive
> - Socket readable event
> - Event dispatch
> - gnutls_record_read(). Here we read the socket, process and retransmit
> if required. If we have no application data, we can (ab)use GNUTLS_E_AGAIN.

It seems to be the only sensible solution so far. It doesn't require
much code, but needs quite some documentation :) I was thinking into
adding another non-fatal error code such as GNUTLS_E_NO_DATA
to avoid overloading of E_AGAIN... but I'll think about it again.

regards,
Nikos