[gnutls-devel] higher level session API?

[Nikos Mavrogiannopoulos]

On Mon, Jan 21, 2013 at 10:41 AM, Tim Ruehsen <tim.ruehsen at gmx.de> wrote:

>> 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_PRIORITY, "NORMAL:-VERS-SSL3.0",
>         // GNUTLS_CHECK_CERTIFICATE, 0, // switch certificate checking on and off
>         / ...
>         NULL); // gcc >= 4 is able to check this with attribute 'sentinel'

That's pretty high level. I think the networking part (i.e. connection
to host and resolving) will have to be kept out. Networking
applications already have this code and in these cases it may be
harder to use that API. I'm thinking of a simpler API that includes
the
priority string, the check certificate flag, and a credentials structure if any.

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

I like those. I'll try to add them (I think the getline is missing
from the current code).

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

That one is tricky because it would mean having explicit thread locks
(global_init isn't thread safe). I think global_init should be called
independently.

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

Is that for the gnutls_session_t API? It's an interesting idea and may
even remove the need of a higher-level API. I'll think about it.

regards,
Nikos