[Help-gnutls] Behavior of gnutls_record_recv()

[Nikos Mavrogiannopoulos]

On Friday 04 January 2008, Laurent Birtz wrote:
> Hello,

> I am considering using GnuTLS as a replacement of openssl for securing
> communications between two processes, A and B. However, I am not using a
> typical client-server model, where the server waits for a query from the
> client and the client waits for the reply from the server. Instead, A
> and B are peer processes, and each one can independently decide at any
> time to send a message to the other side.

This does not really matter. You can send and receive arbitrary messages at 
any time. However why encrypt communication between processes?

> It is possible that one process fill up its input or output queue
> because the two processes are not operating at the same speed.
> Therefore, read and write quenching must be supported. For instance, if
> the input queue of a process is full, then this process must stop
> reading data from the other side but continue writing data to the other
> side.

Is this something you expect from gnutls to do?


> Can I use GnuTLS to fullfill these requirements? I am especially
> concerned with the gnutls_record_recv() and gnutls_record_send()
> functions that can return GNUTLS_E_REHANDSHAKE, GNUTLS_E_INTERRUPTED or
> GNUTLS_E_AGAIN (I am using non-blocking sockets). 

GNUTLS_E_REHANDSHAKE you can ignore totally unless you explicitely request a 
rehandshake.

> For my quenching scheme to be
> implementable, it is important that after a call to gnutls_record_send()
> that returns GNUTLS_E_AGAIN, gnutls_record_get_direction() only returns
> 1, i.e. wait for socket to be writable. Otherwise, if
> gnutls_record_get_direction() returns 0, then this means that more data
> will need to be received from the remote side, and this will bust my
> buffer capacity (in that case, the GnuTLS internal buffer might keep
> growing indefinitely).

the get_direction() function works as you describe so it might suit you.


regards,
Nikos