[gnutls-devel] higher level session API?

Tim Ruehsen tim.ruehsen at gmx.de
Mon Jan 21 10:41:27 CET 2013

Am Thursday 17 January 2013 schrieb Nikos Mavrogiannopoulos:
>  I've trying ways to simplify the gnutls_session_t by adding higher
> level functions. I plan to add function that allow buffering data into a
> session prior to sending, to avoid sending many small TLS records (and
> avoid the whole overhead). Something like:
> ssize_t gnutls_sbuf_queue (gnutls_sbuf_t sb, const void *data,
>                            size_t data_size);
> ssize_t gnutls_sbuf_flush (gnutls_sbuf_t sb);
> However I'm wondering whether a full higher level API over
> gnutls_session_t is needed, that for example does not require to handle
> non-fatal errors (e.g. GNUTLS_E_AGAIN, or
> GNUTLS_E_WARNING_ALERT_RECEIVED). That would be the equivalent of FILE*
> for a TLS session. Any thoughts?

For an application developer, a high level API that can be used 'quick and 
dirty', would reduce the amounts of code and time ot use gnutls.

e.g. like this pseudo code

gnutls_session_t sess = gnutls_open(
	hostname, port,
	// here come *optional* key, value pairs, some examples
	// GNUTLS_READ_TIMEOUT, 5000, // in milliseconds
	// GNUTLS_CHECK_CERTIFICATE, 0, // switch certificate checking on and off
	/ ...
	NULL); // gcc >= 4 is able to check this with attribute 'sentinel'

ssize_t nbytes = gnutls_write(sess, buf, buflen);
ssize_t nbytes = gnutls_printf(sess, "%d - %s\n", ival, str);
ssize_t nbytes = gnutls_read(sess, buf, bufsize);
ssize_t nbytes = gnutls_getline(sess, &buf, &bufsize);
// and why not gnutls_fgets(), though i personally don't like it


The 'open' function should have reasonable default values to work 'right out 
of the box'. It should also do gnutls_global_init() implicitely, if it hasn't 
be done yet.
You still have access to the gnutls_session_t variable, if you need to 
something fancy. 
The key/value approach of course has no 'value type checking' (though it could 
be done by a gcc plugin).

Right now I need ~ 300 lines of C code to implent the open/read/write/close 

And back to your idea with queue/flush:
- inspired from TCP_CORK, my idea would be something like
	do some writes
	gnutls_uncork (or calling it gnutls_flush, if you like)
- or/and implementing something like the Nagle algorithm, kind of automatic 

Just my thoughts...


     Tim Rühsen

More information about the Gnutls-devel mailing list