What happens if client is sending data when rehandshake is issued on the server

[Sam Varshavchik]

I'm trying to understand the proper usage of gnutls_rehandshake(). I have 
only a vague understanding of the technical details of TLS. The man page for 
gnutls_rehandshake says:

# If this function succeeds (returns 0), you must call the
# gnutls_handshake() function in order to negotiate the new parameters.
#
# If the client does not wish to renegotiate parameters he will should with
# an alert message, thus the return code will be 
# GNUTLS_E_WARNING_ALERT_RECEIVED and the alert will be 
# GNUTLS_A_NO_RENEGOTIATION. A client may also choose to ignore this
# message.

So, as I understand this, gnutls_rehandshake() sends a message to the client 
side, and waits for the client to respond.

The man page does not address what happens when the underlying transport is 
non-blocking. I presume what's going to happen is that I'll get a 
GNUTLS_E_INTERRUPTED or GNUTLS_E_AGAIN, I must call 
gnutls_record_get_direction(), wait for the appropriate I/O to be ready, 
then call gnutls_rehandshake() again.

What's not clear to me is what happens when the server calls 
gnutls_rehandshake() while the client is in a middle of sending a record at 
the same time, so instead of receiving the response from the rehandshake 
request, the server receives a data record, that was sent by the client 
before it got the handshake request. What happens to that record, does it 
get discarded, or does gnutls_rehandshake() return an error code that tells 
me that I need to call gnutls_record_recv() to take it 
(GNUTLS_E_UNEXPECTED_PACKET?), then call gnutls_rehandshake() again.

Can this be clarified in the man page?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: </pipermail/attachments/20080913/ada1e151/attachment.pgp>