[RFC] Suggestion for the improvement of the buffering layer

[Jonathan Bastien-Filiatrault]

Here is an implementation suggestion for the improvement of the current
buffering code. This would be mostly for enabling easier DTLS
integration and better maintainability in the future.

Goals:

- Preserve read/write boundaries at the transport level. This is mostly
important for datagram packing.

- Simplify interfaces between layers.

- Eliminate the need for peeking (is this possible/desirable ?).

- Allow pushing data into GnuTLS when the socket becomes readable and
pulling from GnuTLS when the socket becomes writable. This is especially
important for event-driven servers. Read and write callbacks could
therefore be made optional for such programs.


Suggested implementation:

A pyramid of FIFO queues (linked lists would do), one queue per
direction per layer. On the read() side, data would move upward by
forming records from transport buffers. Records would then be
demultiplexed and queued into upper layer protocols (handshake, alert,
application). For the write() direction this would simply be reversed.
This is close to what is done currently except the buffers would be
message-based instead of bytestream-based.

Advantages:

- The separation of "message framing" and message processing. Example: A
buffer_process function would form as much records as it can from the
available transport buffers then a record_read would simply dequeue the
first record from the list and process that record. If there is not
enough data, the transport buffers would be refilled by invoking a
read() on the socket. This would eliminate logic such as read_headers()
then read() from the message processing pipeline and would move that
logic inside the "message framing" code.

- Better separation of concerns, easier to understand code, better
modularity. It can be argued that better understandability, readability
and modularity lead to better security (from programming errors).

Disadvantages:

- Much previously tested/debugged code would be discarded.

- Feasibility not clear (to me).

- Is it worth it ? Would it really be better ?

Thanks for your input,
Jonathan