[Vortex] "no data were waiting on this non-blocking connection" warning

Francis Brosnan Blazquez francis at aspl.es
Tue Mar 25 10:18:17 CET 2008

Hi Jens,

> On 19 Mar '08, at 10:02 AM, Jens Alfke wrote:
> > If only a partial line has been received by the socket, readline  
> > will read past the end of the available data and get an EWOULDBLOCK  
> > error, thus returning -2 and triggering this warning.
> Now that I've actually set a breakpoint in __vortex_frame_readline at  
> the point where it returns -2, I see that this isn't actually what's  
> happening. It hasn't read any characters at all yet (n==1) before  
> getting EWOULDBLOCK; that implies that there were _no_ bytes available.
> What happens is that vortex_tls_ssl_read is called, and its call to  
> SSL_read fails with error SSL_ERROR_WANT_READ. This causes the debug  
> message "SSL_read returned that isn't ready to read: retrying", and  
> vortex_tls_ssl_read then returns -2.
> So it looks as though this is a TLS-specific problem. Raw (encrypted)  
> data has arrived on the socket, but OpenSSL can't decrypt it yet,  
> maybe because it hasn't gotten a complete cipher block. (I don't know  
> how SSL works internally, so this is guesswork.)

You are right at this point. Vortex reader detects incoming data, but at
the raw level, not at the SSL level. 

> I found a good thread about this on the OpenSSL-Users list:
> 	http://www.mail-archive.com/openssl-users@openssl.org/msg39582.html

I'll think about this. Maybe a solution could be to update the I/O layer
reporting to return a new status value signaling that some data arrived,
but still nothing available for the application level.

This would be useful to separate this case from those that the I/O layer
signaled data available but nothing was found (which is an error).

> Here's the most relevant single quote:
> >         If either an SSL_write or an SSL_read results in a WANT_READ  
> > error, it
> > means that neither call can progress until some data is read from the
> > socket. You can retry the operation later, try another operation, or
> > whatever you want to do. You can take the hint that 'select'ing on the
> > socket for readability will likely tell you when the operation is  
> > going to
> > succeed.
> It sounds, then, as though this particular situation I'm seeing is  
> harmless.
> But I still think there's in _general_ a potential for data loss if  
> __vortex_frame_readline gets partway through reading a line and then  
> gets the WANT_READ — the partial line will be ignored, probably  
> causing BEEP syntax/framing errors on the next read, which will abort  
> the connection.

I can confirm you this won't cause data lost at any point. From a
general perspective this is because:

1) Assuming cypher block produced at the SSL layer (at the partner peer)
was created using a complete frame, causing to produce at least 1 up to
N cyphered blocks (due to calls to SSL_write), calls to
__vortex_frame_readline will always return at least the BEEP header. 

2) And, in the case data lost occurs, BEEP channel state will lost sync
and an error will be reported. As long as you send and received data
without error reporting, you are assured that no data is lost.

At the particular case where it is supposed that a partial line is
received and WANT_READ is signaled, this won't happen because it will be
required an incorrect behavior by the remote peer, that is, the BEEP
peer must perform independent send calls to send partial BEEP header


> —Jens
Francis Brosnan Blazquez <francis at aspl.es>

More information about the Vortex mailing list