manpagez: man pages & more
info gnutls
Home | html | info | man
[ << ] [ < ] [ 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 returned GNUTLS_E_INTERRUPTED or GNUTLS_E_AGAIN . In such a case, you might want to call select() or poll() 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.

© manpagez.com 2000-2025
Individual documents may contain additional copyright information.