[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
7.5.1 Asynchronous operation
GnuTLS can be used with asynchronous socket or event-driven programming.
During a TLS protocol session GnuTLS does not block for anything except
calculations. The only blocking operations are due to the transport layer (sockets) functions.
Those, however, in an asynchronous scenario are typically set to
non-blocking mode, which forces them to return EAGAIN
error code instead of blocking.
In that case GnuTLS functions
will return the GNUTLS_E_AGAIN
error code and can be resumed the
same way as a system call would. The only exception is gnutls_record_send,
which if interrupted subsequent calls need not to include the data to be
sent (can be called with NULL argument).
The select
system call can also be used in combination with the
GnuTLS functions. select
allows monitoring of sockets
and notifies on them being ready for reading or writing data. Note however
that this system call cannot notify on data present in GnuTLS
read buffers, it is only applicable to the kernel sockets API. Thus if
you are using it for reading from a GnuTLS session, make sure
the session is read completely. That can be achieved by checking there
are no data waiting to be read (using gnutls_record_check_pending),
either before the select
system call, or after a call to
gnutls_record_recv. GnuTLS does not keep a write buffer,
thus when writing select
need only to be consulted.
In the DTLS, however, GnuTLS might block due to timers
required by the protocol. To prevent those timers from blocking a DTLS handshake,
the gnutls_init should be called with the
GNUTLS_NONBLOCK
flag (see Session initialization).
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This document was generated on January 4, 2012 using texi2html 5.0.