2012/4/23 Salisbury, Mark <mark.salisbury_at_hp.com>:
> Thinking about this a little bit more, I wonder if the SSL write function really needs to write ALL the bytes the client passes in before it returns.  Here's why.  Suppose the client passes in 100 bytes of data to write (a small HTTP GET request).  When we use SSL, we may encrypt that 100 bytes into a different number of bytes; it depends on the encryption algorithm that was negotiated (without extra work we're not going to even know which one was used).  Suppose the plain bytes are converted into 125 bytes. If we write only the first 30 bytes, and we return that to the client, they will call the write function again and start us off at position 30.  Since the previous message was not written fully, it probably wasn't coherent to the receiver when it was decrypted.  Writing 30 bytes (of encrypted data) may not mean that 30 bytes of the unencrypted data was decrypted by the client.
>
> What do you guys think?  Do you agree?  When ssl write methods are passed a buffer to write do they need to write it all or return an error if they are unable to, respecting configured timeouts?
>
> Any encryption experts want to weigh in?

I am not an encryption expert, but as the Schannel decryption routines
themselves are perfectly fine with handling incomplete encrypted data
by asking for more data, I think it should be find to write partial
data to the socket. This is the only way to handle big data transfer
over a slow connection by buffering inside the client.

Remember: packets my be split up anyway, so you can never be sure that
a packet completely arrives at the target endpoint in the same
timeframe and can be read at once. TCP connections are not message
oriented, but stream oriented and this means that the receiving
endpoint should never care about the original send size and just
figure out how much more data is required.

Best regards,
Marc

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2012-04-23