Help regarding MSG_PEEK

Help regarding MSG_PEEK

Post by Sunil Varm » Thu, 17 Aug 2006 22:27:09


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
 
 
 

Help regarding MSG_PEEK

Post by Nils O. Se » Thu, 17 Aug 2006 22:46:52


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.


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.

 
 
 

Help regarding MSG_PEEK

Post by David Schw » Sat, 19 Aug 2006 09:50:40


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
 
 
 

Help regarding MSG_PEEK

Post by Barry Marg » Sat, 19 Aug 2006 12:54:09

In article < XXXX@XXXXX.COM >,




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, XXXX@XXXXX.COM
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 ***
 
 
 

Help regarding MSG_PEEK

Post by Nils O. Se » Sat, 19 Aug 2006 15:55:37


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.
 
 
 

Help regarding MSG_PEEK

Post by David Schw » Sat, 19 Aug 2006 17:40:36


Right.


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
 
 
 

Help regarding MSG_PEEK

Post by David Schw » Sat, 19 Aug 2006 17:47:14


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
 
 
 

Help regarding MSG_PEEK

Post by Valentin N » Sun, 27 Aug 2006 06:32:24


Thu, Aug 17, 2006 at 23:54:09, barmar (Barry Margolin) wrote about "Help regarding MSG_PEEK":

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-
 
 
 

Help regarding MSG_PEEK

Post by Valentin N » Sun, 27 Aug 2006 06:33:08


Fri, Aug 18, 2006 at 01:40:36, davids (David Schwartz) wrote about "Help regarding MSG_PEEK":

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-