Bootstrap parallel connections using session resume ?

[Sebastien Decugis]

Hi Nikos, thank you for your fast answer.

>> 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.
>   
[talking about the client side here]
Ok, so if I understand correctly the transport parameters are not stored
inside the data returned by gnutls_session_get_data2, right ?
What about the credentials (priority, CA, key, ...) ? Do I have to set
them before I set the session data, or does this operation set them for
me (so I don't have to do it at all ?)

>> 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
> there:
> http://www.gnu.org/software/gnutls/manual/html_node/Client-examples.html#Client-examples
>   
Well, I can at least send you pointers to my code with some explanation
so that you get an idea of how I am doing it, and then if you're still
interested I'll try to extract the parts interesting for the manual or
build a demonstration sample. BTW my code is BSD licensed (but I think
it is no problem to extract a small part for the gnutls manual and
release this part under a different license --  at least on my side)

>> 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.
>   
Well, currently I am using the db_* functions only on the server side,
my understanding was that they are not used on the client side, right ?
On the client side, I only get the data of my primary (handshaken)
session and then set this data in all other sessions before handshake.

Anyway for some reason that I don't understand, it seems that now it
started to work properly, and I see successfully resumed sessions -- I
really don't know what I changed in my code for this result -- but I am
not complaining ^^

> What you do is what session resuming was made for.
>   
Ok, great then :)

Thank you again!
Best regards,
Sebastien.

-- 
Sebastien Decugis
Research fellow
Network Architecture Group
NICT (nict.go.jp)