Hi Daniel,

2012/6/13 Daniel Stenberg <daniel_at_haxx.se>
>
> On Wed, 13 Jun 2012, Marc Hoersken wrote:
>
>> If this is the case, we can probably just set CURL_SCHANNEL_BUFFER_INIT_SIZE to BUFSIZE in order to reduce the number of realloc() calls. I would personally keep the code to gracefully handle the need for more buffer space.
>
>
> I was first going to agree and then a second thought struck me. Why would it ever need to handle more data? If it gets called asking for 20K of data, there's nothing in the API that says the function must return that much. We can safely just make BUFSIZE the maximum amount of data the schannel_recv() function can return without it breaking any properly written code!
>
> It would simplify the code without breaking anything...

That's a good plan.

>
>
> Then, as a follow-up improvement the code could probably use the 'buf' buffer immediately instead of separately storing received data in a malloc'ed buffer that is then memcpy()'ed to 'buf'. It would save one malloc/free of a 16K buffer, and also skip memcpy()ing all data that is received. (It will be copied at least once afterwards anyway.)
>

The problem is that we still need to buffer the received encrypted and
unencrypted data since such data can already arive during the initial
SSL/TLS handshake handled by the step-functions. Therefore we need the
buffer to have the data available for the next read. And we also need
this buffer between reads, because there might be an incomplete
encrpyted SSL/TLS packet in the queue. Also there might be more data
decrypted by DecryptMessage than the user wants to read, so we need to
store that already decrypted data, too.

Basically we have to do all the buffering around the DecryptMessage
function as it is not guaranteed that it decrypts the exact amount of
data we want to read or that all encrypted data passed into it is
really decrypted afterwards.

Best regards,
Marc

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