| [ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
7.9.1 Session resumption
Client side
To reduce time and roundtrips spent in a handshake the client can utilize session resumption. This requires the client to retrieve and store the session parameters. On new sessions to the same server the parameters must be re-associated with sessions using gnutls_session_set_data.
Keep in mind that sessions might be expired after some time, and it may be normal for a server not to resume a session even it was requested. That is to prevent temporal session keys from becoming long-term keys. Also note that as a client you must enable, using the priority functions, at least the algorithms used in the last session.
It is highly recommended clients to enable the session ticket extension using gnutls_session_ticket_enable_client in order to allow resumption with servers that do not store any state.
Server side
In order to support resumption a server might do it either by storing the session security parameters in a local database or by using session tickets (see Session tickets) to delegate storage to the client. Because session tickets might not be supported by all clients, servers might combine the two methods.
A storing server needs to specify callback functions to store, retrieve and delete session data. These can be registered with the functions below. The stored sessions in the database can be checked using gnutls_db_check_entry for expiration.
- gnutls_db_set_retrieve_function
- gnutls_db_set_store_function
- gnutls_db_set_ptr
- gnutls_db_set_remove_function
A server utilizing tickets should use gnutls_session_ticket_key_generate to generate a ticket encryption key and call gnutls_session_ticket_enable_server to enable the extension.
| [ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This document was generated on January 4, 2012 using texi2html 5.0.