[openssl-users] BIO_read hangs, how can I know if the server wants to send data?

[Matt Caswell]

On 26/04/16 17:22, Karl Denninger wrote:
> It's split up due to the vagaries of TCP and how it delivers packets.
> 
> In short a local network connection will tend to deliver smaller packets
> of data than a distant one, all things being equal -- but they never
> are.  All you're guaranteed with TCP is a byte-stream that is coherent,
> as was noted in the earlier reply, but you are not guaranteed how many
> bytes will come at once.  When select() receives a ready state for
> reading or a blocking read returns there could be zero (if there's an
> error, exception, or in the case of SSL a possible protocol
> renegotiation) or more bytes available to read.
> 
> There is nothing wrong with either your server or the other end, it's
> just how it works.  Typically the difference is a matter of how things
> match up between how many bytes are received and buffered in your
> protocol stack before you read them .vs. how fast the other end can
> write them and get them to you, which for a wide-area connection usually
> involves a lot of routers in the middle.  With TCP there are additional
> confounding factors, since the protocol itself implements window control
> (size of outstanding transmissions that are allowed), sACK can come into
> play, latency of the circuit and routing points in the middle get
> involved, etc.  For wide-area connections (think Internet) slow-start
> congestion control (which helps avoid a fast server blasting data at a
> rate that could otherwise cause a buffer overflow somewhere in the
> middle, thus requiring a retransmit) also plays a part.


While that is true I don't think it explains the behaviour. A single TLS
record may get split up into multiple small TCP packets (dependent on
the vagaries of the network as you point out). But OpenSSL won't return
app data to the application until it has read the entire TLS record.

Matt