On 3.3.2010, at 21.30, Alex Baule wrote:
But i got some questions about the stream->pos, stream->skip and position of the message and pointer to buffer.
Data is read to buffer, and stream->buffer points to it, stream->skip = 0 and stream->pos = number of bytes available in the buffer.
i_stream_skip() and i_stream_seek() can go forward by simply increasing stream->skip. So stream->buffer + stream->skip always points to the data that i_stream_get_data() returns.
Actual seek() implementation typically resets the stream by changing the offset and setting skip=pos=0.
read() can internally do whatever it wants, as long as the result is consistent. So for example with istream-file the buffer points to a larger buffer and it tries to avoid memmove()ing data, so it tries to add data at the end of the buffer and just increase stream->pos. But it can't always do that, so it then memmove()s the data and sets skip=0.
The buffer from istream-concat is 4096, i read 4096 from get_stream_data, but the result of this read is minor , lets say 4080, but the next read must be from 4096. The "send to client" must be 4080, to send the correctly data decrypted.
My Question is, what the variable used in istream-concat, to send the data to client ? I need to update the stream->pos with my data length ??
I'm not really sure what you're asking here.. i_stream_read() for blocking streams must always read and return at least one byte. There's no guarantees that it ever returns more than one byte at a time. So if you need to read more, keep calling i_stream_read() until it has read as much data as you wanted (i_stream_read_data() does basically that).
istream-concat actually doesn't define buffer's size. It gets the max buffer size from the parent input streams. But it's still just the max. buffer size, nothing guarantees that reads can read that much data at a time.