Re: [PATCH] Improve application data throughput

[Simon Josefsson]

Enrico Scholz <address@hidden> writes:

> This patch allows application data from the remote site to be read in
> larger hunks.  Old code read only one character and passed this to the
> gnutls and gsasl methods. This results (for STARTTLS) in long
>
> | write(1, "X-Bugzilla-Reason: Reporter\r\n"..., 29) = 29
> | poll([{fd=0, events=POLLIN}, {fd=3, events=POLLIN}], 2, -1) = 1 ([{fd=3, 
> revents=POLLIN}])
> | ... [80 lines] ...
> | poll([{fd=0, events=POLLIN}, {fd=3, events=POLLIN}], 2, -1) = 1 ([{fd=3, 
> revents=POLLIN}])
>
> operations where gnutls_record_recv() was called > 80 times which lead
> to a high CPU load.  As I tunnel my IMAP connection with 'gsasl' this is
> an important issue for me.

Hi Enrico.  Ouch, I understand.

> This patch allocates a larger buffer so that gnutls_record_recv() is
> called only once per TLS record.

Thanks.  Your contribution is close to the 10-line limit suggested by
the FSF, would you be willing to sign over the copyright of it to the
FSF?  I can send you papers offline.

> There was added an overflow check too which assumes 1MiB as maximum size
> for a GSASL message.   This value is a blind guess; please adjust when
> specifications require a higher value.

I don't understand this part -- can you explain why it is needed?  

> I see only one problem with the patch:  when remote site stops sending
> in the middle of a TLS record, the 'gsasl' application will hang in
> gnutls_record_recv() forever.

When would that happen?  If the network connection goes down?  I thought
there were some TCP timeouts that would kick in after some time without
any data.

/Simon