|
Home > Archive > Unix Programming > August 2006 > Help regarding MSG_PEEK
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Help regarding MSG_PEEK
|
|
| Sunil Varma 2006-08-16, 1:25 pm |
| Hi,
Is there any way to find the number of bytes filled in the socket
buffer maintained by the kernel.
For suppose if a UDP server application is receiving data on some
port.
How do I know the number of bytes filled in the buffer after it
has received some data without using any recv() or recvfrom() calls.
I have to know the number of bytes in the socket buffer based on
the socket number.
I requirement is, an appliction gives chance to open any number of
sockets(server/client).
The user can send, receive and see the statistics of the socket.
The statistics should display the total number of bytes of data
received at that point in time.
When I tried to do it with recvfrom() with MSG_PEEK, it always
shows the first received data.
So, now can any one suggest me an idea of how to retrieve the
number of bytes stored at a given point in time, in the socket buffer
for a given socket descriptor.
Thanks in advance.
Regards
| |
| Nils O. Selåsdal 2006-08-16, 1:25 pm |
| Sunil Varma wrote:
> Hi,
>
> Is there any way to find the number of bytes filled in the socket
> buffer maintained by the kernel.
> For suppose if a UDP server application is receiving data on some
> port.
> How do I know the number of bytes filled in the buffer after it
> has received some data without using any recv() or recvfrom() calls.
> I have to know the number of bytes in the socket buffer based on
> the socket number.
You should not. Rather read what's thrown at you, and report
how much you've read. This is in most cases much more useful
that reporting what's received but not yet read by the application.
> I requirement is, an appliction gives chance to open any number of
> sockets(server/client).
> The user can send, receive and see the statistics of the socket.
> The statistics should display the total number of bytes of data
> received at that point in time.
> When I tried to do it with recvfrom() with MSG_PEEK, it always
> shows the first received data.
calling recvfrom/recv with the MSG_PEEK flag tells you how big the next
packet to read is going to be. Then you read it (that is call
recv/recvfrom without the MSG_PEEK flag.
Doing this for each packet isn't going to be very efficient. Provide
a buffer that can hold an entier udp packet, or decide on a max
packet size by other means.
| |
| David Schwartz 2006-08-18, 1:22 am |
|
Nils O. Sel=E5sdal wrote:
> calling recvfrom/recv with the MSG_PEEK flag tells you how big the next
> packet to read is going to be. Then you read it (that is call
> recv/recvfrom without the MSG_PEEK flag.
>
> Doing this for each packet isn't going to be very efficient. Provide
> a buffer that can hold an entier udp packet, or decide on a max
> packet size by other means.
It doesn't work either. There's no guarantee that the same datagram
will be "next". UDP datagrams can be discarded at any time.
DS
| |
| Barry Margolin 2006-08-18, 1:22 am |
| In article <1155862240.080795.36320@m73g2000cwd.googlegroups.com>,
"David Schwartz" <davids@webmaster.com> wrote:
> Nils O. Selåsdal wrote:
>
>
> It doesn't work either. There's no guarantee that the same datagram
> will be "next". UDP datagrams can be discarded at any time.
I think we've had this debate before.
While I don't think the spec requires it, I believe every implementation
ever written, and probably ever likely to be written, will not discard
datagrams that have already been buffered. If they run out of buffer
space they'll discard new incoming datagrams rather than replace
existing ones.
Are you aware of counterexamples?
So while it's not a guarantee, it's pretty safe to use MSG_PEEK with
datagram sockets.
--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
| |
| Nils O. Selåsdal 2006-08-18, 7:32 am |
| David Schwartz wrote:
> Nils O. Selåsdal wrote:
>
>
> It doesn't work either. There's no guarantee that the same datagram
> will be "next". UDP datagrams can be discarded at any time.
But not if you already recv'd it with MSG_PEEK.
If an implementation discards the packet inbetween the
recv using MSG_PEEK and the next recv to actually read that data,
it is not conforming to the posix specs.
| |
| David Schwartz 2006-08-18, 7:32 am |
|
Barry Margolin wrote:
> I think we've had this debate before.
Right.
> While I don't think the spec requires it, I believe every implementation
> ever written, and probably ever likely to be written, will not discard
> datagrams that have already been buffered. If they run out of buffer
> space they'll discard new incoming datagrams rather than replace
> existing ones.
>
> Are you aware of counterexamples?
Yes, Linux does. This resulted in a denial of service attack against
inetd.
Basically, you send a UDP packet, which inetd detects with a call to
'select'. Then, as inetd goes to 'recvmsg' the packet, the kernel
decides to drop it. The 'recvmsg' blocks and inetd is in an endless
loop.
DS
| |
| David Schwartz 2006-08-18, 7:32 am |
|
Nils O. Sel=E5sdal wrote:
> But not if you already recv'd it with MSG_PEEK.
> If an implementation discards the packet inbetween the
> recv using MSG_PEEK and the next recv to actually read that data,
> it is not conforming to the posix specs.
I think you are right. The POSIX specification very strongly suggests
that the data peeked at must be retained until the next recv/recvmsg
call. Thank you for pointing me to one case where a UDP packet cannot
be discarded.
DS
| |
| Valentin Nechayev 2006-08-25, 7:28 pm |
| Thu, Aug 17, 2006 at 23:54:09, barmar (Barry Margolin) wrote about "Help regarding MSG_PEEK":
[vbcol=seagreen]
BM> I think we've had this debate before.
BM> While I don't think the spec requires it, I believe every implementation
BM> ever written, and probably ever likely to be written, will not discard
BM> datagrams that have already been buffered. If they run out of buffer
BM> space they'll discard new incoming datagrams rather than replace
BM> existing ones.
Maybe strictness is to leave _at least one_ datagram if any was
reported. (But of course tracking whether MSG_PEEK was called seems
to be senseless so really simplest way is to keep current list and
discard new incomings)
-netch-
| |
| Valentin Nechayev 2006-08-25, 7:28 pm |
| Fri, Aug 18, 2006 at 01:40:36, davids (David Schwartz) wrote about "Help regarding MSG_PEEK":
[vbcol=seagreen]
DS> Yes, Linux does. This resulted in a denial of service attack against
DS> inetd.
Isn't limited to some kernels of 2.2 and 2.4 series?
-netch-
|
|
|
|
|