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) _______________________________________________ Help-gnutls mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-gnutls
