When using SSLStream to send a "large" piece of data (1 megabytes) to a client (already authenticated), the fragmentation / disassembly of the packets that I see, the FAR is greater than when using a regular network stream.
Using asynchronous reading on the client (i.e. BeginRead ()), ReadCallback is repeatedly called with exactly the same data size to the last packet (the rest of the data). With the data I'm sending (this is a zip file), the segments are 16363 bytes long. Note . My receive buffer is much larger than this and resizing is not affected
I understand that SSL encrypts data in chunks no larger than 18 KB, but since SSL sits on top of TCP, I would not have thought that the number of SSL fragments would be related to fragmentation of TCP packets?
In fact, the data takes about 20 times longer to be completely read by the client than with a standard NetworkStream (like on a local host!)
What am I missing?
EDIT:
I'm starting to suspect that the size of the SSLStream receive (or send) buffer is limited. Even if I use synchronous reads (i.e. SSLStream.Read ()), no more data will ever be available, no matter how long I wait before trying to read. This will be the same behavior as if I were to limit the receive buffer to 16363 bytes. Installing Understream NetworkStream SendBufferSize (on the server) and ReceiveBufferSize (on the client) is not affected.