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>
