[gnutls-dev] Re: Intent to implement DTLS

[Guus Sliepen]

On Mon, May 09, 2005 at 01:31:48PM +0200, Nikos Mavrogiannopoulos wrote:

> > 2) "Fix" the current code by (re)introducing a clean separation between
> > the handshake, record and transport layer, and remove the bias towards
> > TCP. This means adding DTLS on top of it will be painless and there
> > won't be lots of code duplication.  However it will touch a lot of
> > existing code.
> Hello,
>  I think this is the best approach to use. But what kind of separation between
> the layers do you need? In what sense they are not separated?

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
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.

What I would like is this:

- A transport layer which provides read() and write() functionality,
  nothing more, nothing less. That means no buffering at all.

- 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.

- 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).

- 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(). 

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
_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.

-- 
Met vriendelijke groet / with kind regards,
    Guus Sliepen <guus at sliepen.eu.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : /pipermail/attachments/20050509/f8e32b20/attachment.pgp