[gnutls-help] gnutls_record_send says it sent more than I told it to!?
m+gnutls at thi.eu.com
Tue Feb 2 19:02:32 CET 2016
On Tue, Feb 02, 2016 at 06:34:26PM +0100, Nikos Mavrogiannopoulos wrote:
> Could it be that you are resuming a previously interrupted send? If the
> previous send was interrupted and returned GNUTLS_E_AGAIN or
> GNUTLS_E_INTERRUPTED then it will be resumed on the next call, unless
> you call gnutls_record_discard_queued().
Yes I guess the logic of my code is somewhat defective (TM).
My issue is the following: because I use non blocking sockets (without
threads), if gnutls_record_send ever returns GNUTLS_E_INTERRUPTED or
GNUTLS_E_AGAIN, I can't busy loop until it works. If I do so, all other
sessions will be stuck. Plus it appears if I kill the socket while I'm
looping on gnutls_record_send, the loop will keep on being executed...
Bottom line is I cannot do:
sent = gnutls_record_send(...);
} while (sent == GNUTLS_E_INTERRUPTED || sent == GNUTLS_E_AGAIN);
So what I do is I queue the write for later: I ask epoll to tell me when
I can actually write (EPOLLOUT) to the socket tied to that TLS session.
Is that what I'm supposed to do?
But before I get this event for that specific socket, I might have done
other things (aka been reading or writing from/to other TLS sessions).
So the question is as follow: does gnutls keep a private buffer per
session (and direction, as in read buffer or write buffer) so when I
call gnutls_record_send with data == NULL and size == 0, it does the
right thing? Or can it get mixed up with other read/writes from
Reading the code, it looks that's what _gnutls_io_write_flush does but
I'm not sure, because so far, I've haven't been able to make the whole
"resume interrupted send" work.
Mathieu Chouquet-Stringer m+gnutls at thi.eu.com
The sun itself sees not till heaven clears.
-- William Shakespeare --
More information about the Gnutls-help