Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Find out number bytes available in the receive buffer

0 views
Skip to first unread message

Andre

unread,
Nov 15, 2009, 11:12:52 AM11/15/09
to
Is there a way to find out the number of bytes available for reading
in the receive buffer without reading it? If so, where can I find more
information about it?

Thanks in advance,

Andre

Philip Paeps

unread,
Nov 15, 2009, 11:23:53 AM11/15/09
to
Andre <sieg...@yahoo.com> wrote:
> Is there a way to find out the number of bytes available for reading
> in the receive buffer without reading it? If so, where can I find more
> information about it?

Perhaps the MSG_PEEK flag is what you're looking for?

- Philip


--
Philip Paeps Please don't email any replies
phi...@paeps.cx I follow the newsgroup.

hundred-and-one symptoms of being an internet addict:
153. You find yourself staring at your "inbox" waiting for new e-mail
to arrive.

Jorgen Grahn

unread,
Nov 15, 2009, 11:42:39 AM11/15/09
to
On Sun, 2009-11-15, Philip Paeps wrote:
> Andre <sieg...@yahoo.com> wrote:
>> Is there a way to find out the number of bytes available for reading
>> in the receive buffer without reading it? If so, where can I find more
>> information about it?
>
> Perhaps the MSG_PEEK flag is what you're looking for?

The FIODREAD ioctl seems to be a better match.

But I suspect it's usually the wrong question. What does the poster
want to use it for?

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

David Schwartz

unread,
Nov 16, 2009, 12:35:31 AM11/16/09
to
On Nov 15, 8:12 am, Andre <sieg1...@yahoo.com> wrote:

> Is there a way to find out the number of bytes available for reading
> in the receive buffer without reading it? If so, where can I find more
> information about it?

Since you cannot use this information to decide whether or not to
read, why not just read in the first place?

DS

David Schwartz

unread,
Nov 16, 2009, 5:28:51 PM11/16/09
to

Just to clarify in case this isn't clear: A protocol will deadlock if
one side says "I'm not going to send any more data until the other
side accepts what I've already sent" and the other side says "I'm not
going to accept what the other side has sent until he sends some
more".

The simplest way to avoid this deadlock is to prohibit one of these
two behaviors. For reasons that should be obvious on reflection, TCP
opts to prohibit the first behavior.

So if you say "I won't call read until enough data gets here", enough
data may *never* get there as the other side waits for you to accept
what it has already sent before it will send any more.

DS

rainball.dh

unread,
Nov 17, 2009, 4:19:40 AM11/17/09
to

"TCP opts to prohibit the first behavior. "?tell me howto prohibit the
first behavior

David Schwartz

unread,
Nov 17, 2009, 5:56:33 PM11/17/09
to
On Nov 17, 1:19 am, "rainball.dh" <rainball...@gmail.com> wrote:

> > So if you say "I won't call read until enough data gets here", enough
> > data may *never* get there as the other side waits for you to accept
> > what it has already sent before it will send any more.

> "TCP opts to prohibit the first behavior. "?tell me howto prohibit the
> first behavior

The same way you prohibit anything -- you simply state that it's
prohibited. A TCP-using application or stack may not refuse to read
data just because enough data has not yet arrived. A TCP-using
application or stack may refuse to send data because the receiving
stack or application has no read or acknowledged that data.

DS

0 new messages