Bootstrap parallel connections using session resume ?

Nikos Mavrogiannopoulos nmav at
Wed Oct 28 07:41:45 CET 2009

Sebastien Decugis wrote:
> Hello,
> I am trying to establish several parallel TLS-protected channels between
> two nodes, like this :
> - establish the first connection (called "master")
> - TLS handshake, verify credentials,
> - If successful, establish the other connections (same endpoints)
> - TLS handshake each of these connections (in parallel in several
> threads), using the same credentials as the master session.
> I got this working, but I would like to optimize the establishment of
> the multi-connections. I can see several ways to do this, but I would
> like to know if they are not mis-use of the GnuTLS library.  What I am
> trying to do is:
> - create several threads after the master handshake and verification,
> and handle each children handshake independently.
> - use session resuming from the master session to accelerate the
> handshake in all children connections.
> Each connection has an independant gnutls_session_t object, but share
> the same credentials structures. On the server side, I have set the same
> session store for all sessions. I need to set the transport pointer in
> the sessions using the gnutls_transport_set_ptr function. Should I do it
> before or after the gnutls_session_set_data on the client side? 

There is no real difference.

> Is there
> anything more to do ?

I don't think so. It looks correct.

> I don't know if it is relevant, my different channels are actually the
> same socket object, but different SCTP streams, and I use customs
> push/pull functions to mux/demux the messages. I can send my code
> showing the actual implementation if you are interested.

Actually I'm interested in the implementation. Would you be interested
to write few words and example push/pull functions on how to use gnutls
over SCTP, to add in the manual? It can be something like the examples

> So far, I was not able to use multithreading and resuming efficiently.
> Most of the sessions fail to resume and fallback to a full handshake. I
> have seen also some strange behavior (store operation with the same key
> but different data) so I am wondering if this whole mechanism is really
> possible with GnuTLS. 

Was this on the server side or client side? If it is on client side, you
should note that you need not and better shouldn't keep the session data
of a resumed session. Just use the session data of the original one or
the last on that didn't success in resuming. If this is not the case
please let me know of the details as well.

I don't really understand what is behind session
> resuming, so please tell me if what I am trying to do is really wrong...

What you do is what session resuming was made for.


More information about the Gnutls-help mailing list