On 04/17/2013 10:45 AM, Michael Kerrisk (man-pages) wrote:
> On Tue, Feb 19, 2013 at 8:10 PM, Pavel Emelyanov <xemul@xxxxxxxxxxxxx> wrote:
>> Since Linux 3.4 there appeared an ability to specify the
>> offset in bytes from which the data will be MSG_PEEK-ed.
>> Describe this socket option in the socket(7) page, where
>> all the other socket options are described.
>>
>> Signed-off-by: Pavel Emelyanov <xemul@xxxxxxxxxxxxx>
>
> Pavel, I have applied this patch, but would like to clarify some
> details. See below.
>
>> ---
>>
>> diff --git a/man7/socket.7 b/man7/socket.7
>> index 2f915da..6177ab1 100644
>> --- a/man7/socket.7
>> +++ b/man7/socket.7
>> @@ -618,6 +618,33 @@ for details on control messages.
>> Gets the socket type as an integer (e.g.,
>> .BR SOCK_STREAM ).
>> This socket option is read-only.
>> +.TP
>> +.BR SO_PEEK_OFF " (since Linux 3.4)"
>> +This option controls the behavior of
>> +.BR recv(2)
>> +system call when used with
>> +.BR MSG_PEEK
>> +flag.
>> +
>> +When this value is negative (kernel sets -1 to all new sockets by default)
>> +the behavior of the
>> +.BR recv(2)
>> +is not affected at all.
>> +When it's set to zero or positive value, peeking the data would occur from
>> +the respective position in bytes. At the same time this offset will be
>> +incremented on the amount of bytes peeked from queue, so that the
>> +subsequent attempt to peek the data would result in next data in queue
>
> So, if I set SO_PEEK_OFF to 5 and do a recv(fs, buf, 10, MSG_PEEK),
> then the offset will end up at 15, and the next MSG_PEEK would
> retrieve at offset 15, right?
Exactly.
>> +(similarly, receiving the data from queue without the
>> +.BR MSG_PEEK
>> +flag will result in respectively decreased offset value).
>
> What does this mean? Is it correct that if I set SO_PEEK_OFF to 5 and
> do a recv(fs, buf, 10, 0), then the offset will end up at 0, and the
> next MSG_PEEK would retrieve at offset 0?
Yes.
> Or, rather, does a recv()
> without MSG_PEEK leave the offset unchanged, so that the next MSG_PEEK
> would retrieve at offset 5?
No. The logic behind that is -- if you set peek-offset and _receive_ some message
(removing it from the queue) the peek-offset is adjusted (decreased) so that the
next message you will _peek_ after that would be the same as if it was if you
didn't do the receive before. (sorry for my English, subjunctive is bad :( ).
IOW, here's the queue:
msg0, msg1, msg2, msg3, msg4
You set peek off to 2 (^ below)
msg0, msg1, msg2, msg3, msg4
^(2)
Now you peek a message, get msg2 and the queue is updated like this:
msg0, msg1, msg2, msg3, msg4
^(3)
i.e. -- peek-off is increased. Next message peek-ed will be msg3.
Now what happens if you receive a message:
msg1, msg2, msg3, msg4
^(2)
msg0 is removed from the queue and the peek-off is decreased down to
2 to still point to the msg3, since you haven't yet peek-ed one.
Hope this makes things more clear.
> Thanks,
>
> Michael
Thanks,
Pavel
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
