]> git.ipfire.org Git - thirdparty/gnutls.git/commitdiff
updated documentation for dtls.
authorNikos Mavrogiannopoulos <nmav@gnutls.org>
Fri, 6 Apr 2012 20:25:19 +0000 (22:25 +0200)
committerNikos Mavrogiannopoulos <nmav@gnutls.org>
Fri, 6 Apr 2012 20:25:19 +0000 (22:25 +0200)
doc/cha-gtls-app.texi
doc/cha-intro-tls.texi

index 382986baf764aa762f1d2fa644ec8c46215c2e85..062e1b55fe47b381a5b0b458611f7e4e9e11983a 100644 (file)
@@ -692,10 +692,14 @@ fatal for the protocol or can be ignored.
 
 @showfuncdesc{gnutls_error_is_fatal}
 
-In DTLS it is advisable to use the extended receive
-function shown below, because it allows the extraction
-of the sequence number. This is required in DTLS because
-messages may arrive out of order.
+Although, in the TLS protocol the receive function can be called
+at any time, when DTLS is used the GnuTLS receive functions must be
+called once a message is available for reading, even if no data are
+expected. This is because in DTLS various (internal) actions
+may be required due to retransmission timers. Moreover,
+an extended receive function is shown below, which allows the extraction
+of the message's sequence number. Due to the unreliable nature of the
+protocol, this field allows distinguishing out-of-order messages.
 
 @showfuncdesc{gnutls_record_recv_seq}
 
index d5c0da7ad72dd9a803fc16a5a0bd0a9664af6191..428319c3d172d16d43733165190ae137fc886029 100644 (file)
@@ -79,9 +79,7 @@ the handshake process is finished, when there is need to receive
 or send data. In @acronym{DTLS} however, due to re-transmission
 timers used in the handshake out-of-order handshake data might
 be received for some time (maximum 60 seconds) after the handshake
-process is finished. For this reason programs using @acronym{DTLS}
-should call the receive functions for every packet received by 
-the peer, even if no data were expected. 
+process is finished. 
 
 The functions to access the record protocol are limited to send
 and receive functions, which might, given