From: Pavel Emelyanov <xemul-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
To: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
Cc: "linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [PATCH] socket.7: Add info about SO_PEEK_OFF option
Date: Mon, 22 Apr 2013 15:43:09 +0400 [thread overview]
Message-ID: <5175224D.2070906@parallels.com> (raw)
In-Reply-To: <CAKgNAkiT7sCgB=o0c7BUcPw_dUxQVt4DrsQHKCiRcYrDmUUTvA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
>> Hope this makes things more clear.
>
> Yep, that helps considerably. I've extensively reworked your text,
> adding quite a bit more detail. Could you check the text below please?
Yup, this is exactly what I was trying to say! Thanks!
> Cheers,
>
> Michael
>
> SO_PEEK_OFF (since Linux 3.4)
> This option, which is currently supported only for unix(7)
> sockets, sets the value of the "peek offset" for the
> recv(2) system call when used with MSG_PEEK flag.
>
> When this option is set to a negative value (it is set to
> -1 for all new sockets), traditional behavior is provided:
> recv(2) with the MSG_PEEK flag will peek data from the
> front of the queue.
>
> When the option is set to a value greater than or equal to
> zero, then the next peek at data queued in the socket will
> occur at the byte offset specified by the option value.
> At the same time, the "peek offset" will be incremented by
> the number of bytes that were peeked from the queue, so
> that a subsequent peek will return the next data in the
> queue.i
>
> If data is removed from the front of the queue via a call
> to recv(2) (or similar) without the MSG_PEEK flag, the
> "peek offset" will be decreased by the number of bytes
> removed. In other words, receiving data without the
> MSG_PEEK flag will cause the "peek offset" to be adjusted
> to maintain the correct relative position in the queued
> data, so that a subsequent peek will retrieve the data
> that would have been retrieved had the data not been
> removed.
>
> For datagram sockets, if the "peek offset" points to the
> middle of a packet, the data returned will be marked with
> the MSG_TRUNC flag.
>
> The following example serves to illustrate the use of
> SO_PEEK_OFF. Suppose a stream socket has the following
> queued input data:
>
> aabbccddeeff
>
> The following sequence of recv(2) calls would have the
> effect noted in the comments:
>
> int ov = 4; // Set peek offset to 4
> setsockopt(fd, SOL_SOCKET, SO_PEEK_OFF, &ov, sizeof(ov));
>
> recv(fd, buf, 2, MSG_PEEK); // Peeks "cc"; offset set to 6
> recv(fd, buf, 2, MSG_PEEK); // Peeks "dd"; offset set to 8
> recv(fd, buf, 2, 0); // Reads "aa"; offset set to 6
> recv(fd, buf, 2, MSG_PEEK); // Peeks "ee"; offset set to 8
> .
>
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
prev parent reply other threads:[~2013-04-22 11:43 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-19 19:10 [PATCH] socket.7: Add info about SO_PEEK_OFF option Pavel Emelyanov
[not found] ` <5123CE11.5060900-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2013-04-16 18:35 ` Pavel Emelyanov
2013-04-17 6:45 ` Michael Kerrisk (man-pages)
[not found] ` <CAKgNAkhoStgFnweOABOx3GQnq4Y9NaOambo2UKHcA_7DZiA7SA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-04-17 7:39 ` Pavel Emelyanov
[not found] ` <516E5197.3030708-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2013-04-20 6:47 ` Michael Kerrisk (man-pages)
[not found] ` <CAKgNAkiT7sCgB=o0c7BUcPw_dUxQVt4DrsQHKCiRcYrDmUUTvA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-04-22 11:43 ` Pavel Emelyanov [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5175224D.2070906@parallels.com \
--to=xemul-bzqdu9zft3wakbo8gow8eq@public.gmane.org \
--cc=linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.