*** empty log message ***

4 files changed, 37 insertions, 17 deletions

diff --git a/doc/tex/Makefile.am b/doc/tex/Makefile.am
index afcd846c45..99461d7d2b 100644
--- a/doc/tex/Makefile.am
+++ b/doc/tex/Makefile.am
@@ -4,7 +4,7 @@ EXTRA_DIST = gnutls.tex gnutls.ps gnutls.html  \
 	cover.tex.in
 
 TEX_OBJECTS = gnutls.tex ../../lib/gnutls-api.tex serv1.tex ex1.tex ex2.tex ex3.tex fdl.tex \
-	macros.tex cover.tex ciphersuites.tex
+	macros.tex cover.tex ciphersuites.tex resumedb.tex
 
 gnutls.ps: $(TEX_OBJECTS)
 	-$(LN_S) ../../lib/gnutls-api.tex .
diff --git a/doc/tex/ex1.tex b/doc/tex/ex1.tex
index 71fdd333c1..c0a15f6030 100644
--- a/doc/tex/ex1.tex
+++ b/doc/tex/ex1.tex
@@ -1,3 +1,5 @@
+\subsection{Client with Resume capability example}
+\label{resume-example}
 \begin{verbatim}
 
 #include <stdio.h>
diff --git a/doc/tex/gnutls.tex b/doc/tex/gnutls.tex
index a6092ed318..0fe9702e7e 100644
--- a/doc/tex/gnutls.tex
+++ b/doc/tex/gnutls.tex
@@ -69,6 +69,8 @@ The following authentication schemas are supported in \gnutls:
 
 \input{ciphersuites}
 
+\input{resumedb}
+
 \section{Client Examples}
 This section contains examples of TLS and SSL clients, using \gnutls. 
 
@@ -90,22 +92,6 @@ This function should be called after a successful
 
 \input{ex3}
 
-\subsection{Resuming Sessions}
-\par
-The 
-\hyperref{gnutls\_handshake()}{gnutls\_handshake() (see Section }{ for more information)}{gnutls_handshake}
- function, is expensive since
-a lot of calculations are performed. In order to support many fast connections to
-the same server a client may use session resuming. {\bf Session resuming} is a
-feature of the {\bf TLS} protocol which allows a client to connect to a server,
-after a successful handshake, without the expensive calculations (ie. use the previously
-established keys). \gnutls supports this feature, and this example illustrates a
-typical use of it (This is a modification of the simple client example).
-
-\par
-Keep in mind that sessions are expired after some time (for security reasons), thus
-it may be normal for a server not to resume a session even if you requested that.
-
 \input{ex1}
 
 \subsection{Simple Client example with SRP Authentication}
diff --git a/doc/tex/resumedb.tex b/doc/tex/resumedb.tex
new file mode 100644
index 0000000000..3129df1b20
--- /dev/null
+++ b/doc/tex/resumedb.tex
@@ -0,0 +1,32 @@
+\section{Resuming Sessions}
+\par
+The 
+\hyperref{gnutls\_handshake()}{gnutls\_handshake() (see Section }{ for more information)}{gnutls_handshake}
+ function, is expensive since a lot of calculations are performed. In order to support many fast connections to
+the same server a client may use session resuming. {\bf Session resuming} is a
+feature of the {\bf TLS} protocol which allows a client to connect to a server,
+after a successful handshake, without the expensive calculations (by using the previously
+established keys). \gnutls supports this feature, and the
+example \hyperref{resume client}{resume client (see Section }{ for more
+information)}{resume-example} illustrates a typical use of it (This is a modification of the simple client example).
+\par
+Keep in mind that sessions are expired after some time (for security reasons), thus
+it may be normal for a server not to resume a session even if you requested that.
+
+\subsection{Resuming internals}
+The resuming capability (mostly in the server side) is one of the problems of a thread-safe TLS
+implementations. The problem is that all threads must share information in
+order to be able to resume sessions. The gnutls approach is, in case of a
+client, to leave all the burden of resuming to the client (ie. copy and keep the
+nesessary parameters etc.).
+\par
+The server side is different\footnote{Future versions of gnutls may be
+different}. 
+Here the server only specifies a DB file to be
+used. This DB file is used to store the sessions' required parameters for
+resuming (and this means that this file contains very sensitive information,
+such as encryption keys). In a multi-threaded application every thread can
+read from the DB file and access all previously established sessions, but
+only one thread can write at a time. The current behaviour of gnutls is
+not to block and wait for the DB to be ready for writing, but continue the
+process normally (and do not save the parameters).