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

Andre <sieg1974@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
philip@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.

On Sun, 2009-11-15, Philip Paeps wrote:
> Andre <sieg1974@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   .

On Nov 15, 8:12=A0am, 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

On Nov 15, 9:35=A0pm, David Schwartz <dav...@webmaster.com> wrote:
> On Nov 15, 8:12=A0am, 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?

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

On Nov 17, 6:28=A0am, David Schwartz <dav...@webmaster.com> wrote:
> On Nov 15, 9:35=A0pm, David Schwartz <dav...@webmaster.com> wrote:
>
> > On Nov 15, 8:12=A0am, 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 mor=
e
> > > information about it?
>
> > Since you cannot use this information to decide whether or not to
> > read, why not just read in the first place?
>
> 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

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

On Nov 17, 1:19=A0am, "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