[gnutls-help] Asynchronous operation.

[Carlo Wood]

Both, this message (see below) and my question of a week or so ago
have been completely ignored.

In the mean time I figured out that gnutls does not support this
myself. So, I'll switch to another library I guess.

On Sat, 27 Oct 2018 00:20:13 +0200
Carlo Wood <carlo at alinoe.com> wrote:

> Hello list,
> 
> I wrote a library (GPL) that aims for not creating more threads
> than CPU cores. This library provides a thread pool and does
> all timer and socket/filedescriptor monitoring.
> 
> At the moment I can create a TCP connection and read/write data
> in a 100% non-blocking way by means of callback functions (well,
> not really - but that would be the same); when it is possible
> to write data and I have data, a function is called that allows
> me to do that: write the data. When a socket has data then a
> function is called that allows me to read that data.
> 
> I now wish to add TLS layer to this. In order to (still) never
> put a thread to sleep (except a specialized one that does the calls
> to epoll) I need this gnutls to provided the following
> interface: it should call a callback function (that I configured)
> to tell me that it is interested in reading and/or writing (not
> to get actual data or write it - just to tell me that it is ready
> to do so). When there is nothing to do for the library, it should
> return from whatever function I called (it should never go to sleep
> internally, or internally wait for anything (like sockets or a
> timer)).
> 
> When the library indicates it is interested in reading or writing
> data, I will call functions of the library as soon as this is
> possible; ie, when the library wants to read I can provide it a
> non-blocking fd that it can read from, or I can do reading and
> buffering myself and call a function of the library providing a
> buffer pointer and the number of characters available in the buffer.
> [ Ideal would be when the gnutls also provided an end-of-message
> detection function that I could use to know when I have a complete
> message, so that my library can provide strictly contiguous messages,
> but this is not absolutely necessary (the result I'd expect is that
> the library will make a copy of the data that I provide; which is
> slower, but that is ok I suppose). If each message always starts with
> a header that contains the total length of that message then I provide
> the end-of-message decoder myself of course. ]
> 
> Reading https://gnutls.org/manual/gnutls.html#Asynchronous-operation
> I'm a bit lost however... it seems kind of clear, but not entirely ;).
> 
> Is there client example code available somewhere that shows how
> this can be done?
> 
> Many thanks for your time,
> Carlo Wood
> 
> PS In case anyone is interested; my library in question exists of many
> git submodules, each of which alone hardly ever make a whole; the only
> currently existing repository that brings it all together is
> https://github.com/CarloWood/ai-statefultask-testsuite
> and the submodule that I'd add the TLS to will be
> https://github.com/CarloWood/evio
> 
> PS2 About the end-of-message detection: I don't want to ever copy
> data around in memory unless absolutely necessary: data is read from
> a socket into a buffer that is considerably larger than the average
> message size; whenever all data in the buffer is processed, it starts
> again at the beginning of the buffer. Only in the event that data
> comes in faster than it can be processed it might happen that a
> message wraps over the end into a newly allocated block. In that case
> (which should seldom happen) I prefer to make a copy into a new buffer
> to make the message contiguous because decoding contiguous messages
> is usually much faster and normally they are contiguous anyway.
> In order to know if a (new) message wraps over the end of the current
> buffer I simply look if 1) the current memory block is full, 2) there
> is no 'end-of-message' between where we are and the end of the current
> block. This can of course be done much much faster than decoding
> the message, especially for binary protocols that simply have the
> length of a message in the header of each message (or have fixed size
> messages, etc).
> 



-- 
Carlo Wood <carlo at alinoe.com>