[gnutls-help] gnutls_record_send says it sent more than I told it to!?

[Mathieu Chouquet-Stringer]

Hello Nikos,

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:

	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
different sessions?

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