recv()==0 question

Hi,


I have been trying to workout a situation, where select() indicates that I
can read from my
socket, but the recv() function results with 0.

I have noticed that there are 2 different implementations of recv()
regarding the 0 result:
1) if recv() returns 0, then the connection has been gracefully closed
or
2) if recv() returns 0, it simply means there is no data to be read.

First of all, how can I know which implementation is used on my system?
(My development system is RedHat6.2 kernel 2.2.14, but my target platform
has a custom kernel 2.2.18 I believe).

In my case (redhat) the select() routine indicates that the socket can be
read from,
but recv() returns 0. This could indicate that the connection was gracefully
closed.
(Later on I got a SIGPIPE error, so this REALLY INDICATES that my connection
was closed I think.)

I hope somebody can shed some light on this matter.
Thanks.
--

Many regards
Bonny

Bonny Gijzen <bonny_dot_gijzen_at_q-lite_dot_net> wrote:

> I have been trying to workout a situation, where select() indicates
> that I can read from my socket, but the recv() function results with
> 0.

This is normal. As, just like a listening socket is `readable' when a
connection has been completed, a socket is also `readable' when it has
been closed.

> I have noticed that there are 2 different implementations of recv()
> regarding the 0 result: 1) if recv() returns 0, then the connection
> has been gracefully closed or 2) if recv() returns 0, it simply means
> there is no data to be read.

Where did you see 2? 1 is the behaivour you will see under Linux, and
under most (all?) Unix systems. It's the standard behaivour anyway.

> First of all, how can I know which implementation is used on my system?
> (My development system is RedHat6.2 kernel 2.2.14, but my target platform
> has a custom kernel 2.2.18 I believe).

They should always be the same.

> I hope somebody can shed some light on this matter.

You would do well to get yourself a copy of `Unix Network Programming:
Volume 1'. Version 3 is the latest.

--
Cameron Kerr
(E-Mail Removed) : http://nzgeeks.org/cameron/
Empowered by Perl!

Bonny Gijzen <bonny_dot_gijzen_at_q-lite_dot_net> wrote:

> Hmmm.....Normally in my case select() just timesout if there is no
> data to be read. In 99.9% of all cases, if select() indicates there
> is something to read, then there *is* data to read from the socket. On
> a very rare occasion though there is nothing to be read (recv returns
> 0).
>
> So the behaviour I am seeing does not comply with your explanation.
> How come?

From what you say, it does comply. read() returns zero because the
connection has been closed, and there is no data left to read from it.

If you're still stuck, post some code (just a bit)

--
Cameron Kerr
(E-Mail Removed) : http://nzgeeks.org/cameron/
Empowered by Perl!

> > I have been trying to workout a situation, where select() indicates
> > that I can read from my socket, but the recv() function results with
> > 0.
>
> This is normal. As, just like a listening socket is `readable' when a
> connection has been completed, a socket is also `readable' when it has
> been closed.

Hmmm.....Normally in my case select() just timesout if there is no data to
be read.
In 99.9% of all cases, if select() indicates there is something to read,
then there *is* data to read from the socket. On a very rare occasion though
there is nothing to be read (recv returns 0).

So the behaviour I am seeing does not comply with your explanation. How
come?
I know that select() doesn't indicate there is data, but merely that to
socket is able to be read.
I guess I need to use some peek() instead?
(Pls note that the select() function usage wasn't my idea. My soft is based
on existing source, which used the select() function to see if there is
data)

> > I have noticed that there are 2 different implementations of recv()
> > regarding the 0 result: 1) if recv() returns 0, then the connection
> > has been gracefully closed or 2) if recv() returns 0, it simply means
> > there is no data to be read.
>
> Where did you see 2? 1 is the behaivour you will see under Linux, and
> under most (all?) Unix systems. It's the standard behaivour anyway.

The MAN pages on my Redhat6.2 system say:

"RETURN VALUES : These calls return the number of bytes received, or -1 if
an error occured."

Now, at the time I assumed that a result of 0 would mean that there is
simply no data, and no error.

> > First of all, how can I know which implementation is used on my system?
> > (My development system is RedHat6.2 kernel 2.2.14, but my target
platform
> > has a custom kernel 2.2.18 I believe).
>
> They should always be the same.

Ok.

> > I hope somebody can shed some light on this matter.
>
> You would do well to get yourself a copy of `Unix Network Programming:
> Volume 1'. Version 3 is the latest.

Yes I understand. Assuming that the linux kernels I use are compliant, and I
guess they are.

Thanks again,
Bonny

> > Hmmm.....Normally in my case select() just timesout if there is no
> > data to be read. In 99.9% of all cases, if select() indicates there
> > is something to read, then there *is* data to read from the socket. On
> > a very rare occasion though there is nothing to be read (recv returns
> > 0).
> >
> > So the behaviour I am seeing does not comply with your explanation.
> > How come?
>
> From what you say, it does comply. read() returns zero because the
> connection has been closed, and there is no data left to read from it.

Ah ok I think now I understand it:

Select() indicates the socket is readable, which could mean that either:

a) there is some data to be read
or
b) the socket connection has been closed (which recv() will indicate with
resulting 0)

Am I correct?
If above is true, then my code is OK. I was just curious.

Rgs Bonny

In article <40d186ac$0$8992$(E-Mail Removed) t>
bonny_dot_gijzen_at_q-lite_dot_net (Bonny Gijzen) writes:

>Ah ok I think now I understand it:
>
>Select() indicates the socket is readable, which could mean that
>either:
>
>a) there is some data to be read
>or
>b) the socket connection has been closed (which recv() will indicate
>with resulting 0)
>
>Am I correct?
>If above is true, then my code is OK. I was just curious.

Yes, you're right on the money. If you want to continue processing
even if no data is available, you must set your socket non-blocking.
Then, if no data is ready, recv() will return -1 and errno will be
set to EAGAIN. You'll have to test for this and treat it differently
from other conditions which really _are_ errors.

Even under Windows recv() works the same way. Except, of course,
their NIH complex requires you to do a GetLastError() and check
the result for WSAEWOULDBLOCK instead of looking at errno.

--
/~\ (E-Mail Removed)lid (Charlie Gibbs)
\ / I'm really at ac.dekanfrus if you read it the right way.
X Top-posted messages will probably be ignored. See RFC1855.
/ \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!