Jamie Lokier ha scritto:

>Legolas wrote:
>
>
>>>That is not the case.
>>>
>>>We know there is data available to read (but we cannot know how much).
>>>We must already have a known buffer area to store data in, then call
>>>recv() to get the data and then store it in the buffer (possibly after
>>>some "decoding" like SSL, chunked HTTP and similar).
>>>
>>>Therefore, we must already have been given a buffer pointer (and size)
>>>
>>>
>>>from the application layer where we can store the received data BEFORE
>>
>>
>>>we call the write callback.
>>>
>>>
>
>If you want sinks and sources to handle: files, network streams,
>further processing in memory, SSL, compression, HTTP chunk
>encoding, etc., and you want them all to use the minimum number of
>copies, then you _cannot_ use a fixed pattern such as "library
>calls application to request buffer; library stores data into
>application buffer".
>
>That's the pattern Legolas suggests, and it works fine when data is
>simply being read from a socket.
>
>
That was the wrong pattern I was looking at before; in the last reply,
give a look at the pseudo-code, which allows the library to process
socket raw data correctly.

>But, for example, if the library needs to decompress the data (zlib)
>or decrypt it (SSL), then that interface actually causes more copies
>than necessary. For example, the zlib decompression algorithm
>_requires_ all the incoming data to be stored in a 32k circular buffer
>- that's part of the algorithm.
>
>Legolas' pattern requires each decompressed data chunk to be then
>_copied_, from the algorithm's 32k buffer, to the application's
>supplied buffer. That is more copies than necessary.
>
>
No, the library is aware of a destination buffer and can write to it.
Again, give a look at the pseudo-code in the previous reply please.

I think your write-up is simply excellent and all of its points should
be developed, I will consider it when I'll try to write a client source
(pseudo code) as suggested by Daniel Stenberg.

Thank you
Received on 2005-12-05