Socket SO_RCVBUF information.

[Terry Sanders]

Hi,

For various reasons I need to how many packets are queued in the SO_RCVBUF
of a udp socket. I know there are various mechanisms for detecting if there
is one
or more packets queued, but I cant find anything to tell me exactly how many
are queued.
Does anybody have any idea how to get this information. I currently need
this for linux.

Any ideas would be appreciated.

Regards

Terry
PS. Replace "nobody" in the email address with "trs" to email me.

[David Schwartz]

"Terry Sanders" <no****@vertone.co.uk> wrote in message
news:Um*******************@news-binary.blueyonder.co.uk...

For various reasons I need to how many packets are queued in the SO_RCVBUF
of a udp socket. I know there are various mechanisms for detecting if there is one
or more packets queued, but I cant find anything to tell me exactly how many are queued.
Does anybody have any idea how to get this information. I currently need
this for linux.

I don't think anybody will be able to answer your question without
understanding your actual problem. Just hearing your proposed solution is
insufficient for us to formulate a solution that will work.

DS

[Terry Sanders]

"Barry Margolin" <ba************@level3.com> wrote in message
news:KO***********@news.level3.com...

In article <Um*******************@news-binary.blueyonder.co.uk>,
Terry Sanders <no****@vertone.co.uk> wrote:

For various reasons I need to how many packets are queued in the SO_RCVBUFof a udp socket. I know there are various mechanisms for detecting if thereis one
or more packets queued, but I cant find anything to tell me exactly how manyare queued.
Does anybody have any idea how to get this information. I currently need
this for linux.
You could try using the FIONREAD ioctl, but I don't know if it's

guaranteed to work or portable. However, if it works it will tell you how many bytes
are in the queue, not how many packets.

Why do you need to know this, anyway? If another packet arrives after the
call returns, the information will be wrong.

Doesn't FIONREAD return the number of bytes in the next udp packet
(+ addr len) as opposed to the number of bytes in the RCVBUF?

What I'm doing is developing an application to test the capabilities
of another. At any one time it has to decide whether to send the next
packet, read a packet, act on a packet already read (which may involve
sending another packet), process timeouts on previous packets sent or
any one of a number of other things. By knowing how many packets are in
the read queue the application can make decisions on whether in can
safely ignore the contents of the read queue, until the next pass, in
favour of processing other parts which may be running behind.

Terry Sanders

[Rick Jones]

In comp.protocols.tcp-ip Terry Sanders <no****@vertone.co.uk> wrote:

Doesn't FIONREAD return the number of bytes in the next udp packet
(+ addr len) as opposed to the number of bytes in the RCVBUF?
On HP-UX at least the manpage for ioctl(5) states:

FIONREAD
Returns in the long integer whose address is arg the
number of characters immediately readable from the
device file.
What I'm doing is developing an application to test the capabilities
of another. At any one time it has to decide whether to send the next
packet, read a packet, act on a packet already read (which may involve
sending another packet), process timeouts on previous packets sent or
any one of a number of other things. By knowing how many packets are in
the read queue the application can make decisions on whether in can
safely ignore the contents of the read queue, until the next pass, in
favour of processing other parts which may be running behind.

Sounds like knowing how full the socket buffer with FIONREAD would be
sufficient - assuming you know in advance the typical datagram sizes
so you know whether or not you are within N datagrams of overflowing
the socket buffer.

rick jones
--
a wide gulf separates "what if" from "if only"
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to raj in cup.hp.com but NOT BOTH...