[RFC] Suggestion for the improvement of the buffering layer

Nikos Mavrogiannopoulos nmav at gnutls.org
Wed Aug 5 20:48:14 CEST 2009

Jonathan Bastien-Filiatrault wrote:

> 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

 If I understand well you propose using something similar to skb's in
linux?  Can you give me an example of your proposal? Say in the TCP case
we received a handshake message in 3 different packets and one is not
yet received. How the processing will go before the 4th is received and
how after that?

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

Replacing ugly code with simpler one (or more efficient one) does not
count as disadvantage to me.

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

I'm curious whether something like that would be more efficient. In
theory, if I get your idea correct, it would have less memcopy etc but
in practice we are spending more time in decrypting/encrypting and the
current code has quite reduced memcpy. However there is still space for

If you are asking a go or not go, I'd say that it's up to you. In any
case I am curious of any results and more design information.


More information about the Gnutls-devel mailing list