Bootstrap parallel connections using session resume ?

[Nikos Mavrogiannopoulos]

Sebastien Decugis wrote:

> [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 ?

Indeed.

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

Those are needed to be set since the server might decide not to resume.
If he doesn't typically they are ignored.

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

That would be perfect. Please send me.

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

Correct.

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

I'm quite curious on the previous behavior, where you noticed the same
session ID being save twice in server side. It seems the server was
wrongly trying to overwrite the initial session parameters with the
resumed one. The attached patch should fix what you have noticed.
(what you see now might be a timing issue if all the clients connect
before the server has overwritten the initial parameters).


regards,
Nikos

-------------- next part --------------
A non-text attachment was scrubbed...
Name: resuming.patch
Type: text/x-patch
Size: 1165 bytes
Desc: not available
URL: </pipermail/attachments/20091028/01ca3adb/attachment.bin>