All of lore.kernel.org
 help / color / mirror / Atom feed
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

      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.