[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
6.5.1 Asynchronous operation
GnuTLS can be used with asynchronous socket or event-driven programming.
The approach is similar to using Berkeley sockets under such an environment.
The blocking, due to network interaction, calls such as
gnutls_handshake, gnutls_record_recv,
can be set to non-blocking by setting the underlying sockets to non-blocking.
If other push and pull functions are setup, then they should behave the same
way as recv
and send
when used in a non-blocking
way, i.e., set errno to EAGAIN
. Since, during a TLS protocol session
GnuTLS does not block except for network interaction, the non blocking
EAGAIN
errno will be propagated and GnuTLS functions
will return the GNUTLS_E_AGAIN
error code. Such calls 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
that any cached data are 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 no additional actions are required.
Although in the TLS protocol implementation each call to receive or send function implies to restoring the same function that was interrupted, in the DTLS protocol this requirement isn’t true. There are cases where a retransmission is required, which are indicated by a received message and thus gnutls_record_get_direction must be called to decide which direction to check prior to restoring a function call.
- Function: int gnutls_record_get_direction (gnutls_session_t session)
session: is a
gnutls_session_t
structure.This function provides information about the internals of the record protocol and is only useful if a prior gnutls function call (e.g.
gnutls_handshake()
) was interrupted for some reason, that is, if a function returnedGNUTLS_E_INTERRUPTED
orGNUTLS_E_AGAIN
. In such a case, you might want to callselect()
orpoll()
before calling the interrupted gnutls function again. To tell you whether a file descriptor should be selected for either reading or writing,gnutls_record_get_direction()
returns 0 if the interrupted function was trying to read data, and 1 if it was trying to write data.Returns: 0 if trying to read data, 1 if trying to write data.
Moreover, to prevent blocking from DTLS’ retransmission timers to block a
handshake, the gnutls_init function should be called with the
GNUTLS_NONBLOCK
flag set (see Session initialization). In that
case, in order to be able to use the DTLS handshake timers, the function
gnutls_dtls_get_timeout should be used to estimate when to call
gnutls_handshake if no packets have been received.
[ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This document was generated on February 9, 2014 using texi2html 5.0.