<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 4/26/2016 11:12, Hanno Böck wrote:<br>
<blockquote cite="mid:20160426181243.151efddb@pc1" type="cite">
<pre wrap="">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?
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
</blockquote>
It's split up due to the vagaries of TCP and how it delivers
packets.<br>
<br>
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.<br>
<br>
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.<br>
<br>
<div class="moz-signature">-- <br>
Karl Denninger<br>
<a href="mailto:karl@denninger.net">karl@denninger.net</a><br>
<i>The Market Ticker</i><br>
<font size="-2"><i>[S/MIME encrypted email preferred]</i></font>
</div>
</body>
</html>