[gnutls-dev] Re: Intent to implement DTLS

[Nikos Mavrogiannopoulos]

On Monday 09 May 2005 14:38, Guus Sliepen wrote:

> As I see it there are three layers: transport, record and handshake. The
> transport layers deals with sending and receiving raw data. The record
> layer reads and writes records from/to the transport layer, and it handles
> encryption and compression. The handshake layer reads and writes
> handshake records and sets the encryption and compression parameters of
> the record layer. As far as I have seen, the transport layer is in
> gnutls_buffer.c, the record layer in gnutls_record.c and the handshake
> layer in gnutls_handshake.c. However in gnutls_buffer.c I see the
> function _gnutls_handshake_io_send_int() which seems to suggest that the
> transport layer receives knowledge about what kind of record types it
No this is not really the case. The gnutls_buffers.c is more than the
transport functions. The gnutls_io_handshake stuff are wrappers over
record_send/recv_int(). 

There is a case where the record protocol has to know the handshake packet
it expects. This is the case for the client hello, thus it can parse an SSL 
2.0 packet. In all other cases this information is not used/needed.

> has to deal with. In gnutls_record.c the function _gnutls_recv_int(),
> which I assume tries to read a record, looks at the record type and
> depending on the type does different things with it. There are more
> examples of functions which do not stay within their own layer.
No gnutls_recv_int() does not really care about the data it receives.

> - A transport layer which provides read() and write() functionality,
>   nothing more, nothing less. That means no buffering at all.
These are provided by the user in session->internals._gnutls_pull_func
or the default recv()/send() are used.

> - A record layer which can read and write records. It buffers read()s
>   and write()s from the transport layer if necessary (ie, it buffers
>   until it has at least one whole record). This layer also encrypts and
>   compresses data. It does not look at the record type field at all.
This is not what record_recv() provides?

> - A handshake layer which can read and write handshake messages. It
>   buffers records it reads and writes from the record layer if necessary
>   (ie, buffers until it has at least one whole handshake message).
I think that you seek for the io_handshake() functions...

> - The top layer which does the whole handshake protocol and handles
>   application_data records. The handshake protocol is done by
>   gnutls_handshake(), the application data is done by
>   gnutls_record_send/recv().
This one will be probably much different than the current ones, thus
they functions in gnutls_handshake() might not fit. Anyway check
handshake_recv(), handshake_recv_header() etc.

> As an example, when gnutls_handshake() is called and it is in a state
> where it should receive a handshake message from the other end, it would
> call _gnutls_handshake_recv(), which in turn would do a
handshake_io_recv_int() and in turn
gnutls_record_recv_int()
> _gnutls_record_recv() which would do a _gnutls_transport_recv(). If at
> any point not enough data is read to return a whole record or handshake
> message, GNUTLS_E_AGAIN is returned. If there is enough data for a whole
> handshake message, then _gnutls_handshake_recv() will return without an
> error and the gnutls_handshake() function can process the handshake
> message.

-- 
Nikos Mavrogiannopoulos