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

[Karl Denninger]

On 4/26/2016 11:12, Hanno Böck wrote:
> Thanks for both your answers, that was very helpful (although it
> probably means what I'm trying to do is more complicated than I
> thought)...
>
> One more question you might be able to answer:
> When I run my test code and connect to google.com I get the following
> bytes read for each BIO_read call:
> 1024
> 365
> 289
>
> When I run these against my own server (relatively standard
> apache2.4+openssl setup) I get very different numbers:
> 240
> 287
> 2
> 588
> 2
> 41
> 2
> 115
> 2
> 12
> 2
> 110
> 2
> 69
> 2
> 20
> 2
> 6
> 2
> 34
> 2
> 17
> 2
> 12
> 2
> 37
> 2
> 290
> 2
> 6
> 5
>
> Why is this so much more split up? And to what correspond these
> BIO_read chunks on the protocol level? Are these TLS records? TCP
> packets? Is there something horribly wrong with my server config
> because it splits them up in so many small parts?
>
>
>
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.

-- 
Karl Denninger
karl at denninger.net <mailto:karl at denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160426/d5d656b1/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2996 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160426/d5d656b1/attachment.bin>