recv() function in QNX TCP/IP

In Windows, a return result of 0 from the socket recv() calls means that
the other end has shutdown its socket. An exception to this is if you call
recv() with a parameter requesting 0 bytes (yes, I had a silly loop and did
this). In this case there is no error and work can be continued with the
socket.

It does not explicitly say that the QNX sockets have the same behavior.
I have been getting some zeroes, and I am not sure if this means that the
connection is gone.

Does anybody know?

Robert Kindred

“Robert Kindred” <RKindred@SwRI.edu> wrote in message
news:ck3i07$fk5$1@inn.qnx.com

In Windows, a return result of 0 from the socket recv() calls means that
the other end has shutdown its socket. An exception to this is if you
call
recv() with a parameter requesting 0 bytes (yes, I had a silly loop and
did
this). In this case there is no error and work can be continued with the
socket.

It does not explicitly say that the QNX sockets have the same behavior.
I have been getting some zeroes, and I am not sure if this means that the
connection is gone.

Does anybody know?

0 means there is no data in the received buffer, it’s not an error.

Robert Kindred

The QNX help page for “recv” says “if no messages are available
at the socket, the receive call waits for a
message to arrive, unless the socket is nonblocking – see ioctl() – in
which case -1 is returned and the external variable errno is set to
EWOULDBLOCK.”

But, in fact, what seems to happen if no data is available is that
you get a normal return with 0 bytes, at least some of the time.
At least in 6.21.

Since you don’t normally call “recv” until you get a success return
from “select”, the no-data case isn’t usually exercised.

John Nagle

Mario Charest wrote:

“Robert Kindred” <> RKindred@SwRI.edu> > wrote in message
news:ck3i07$fk5$> 1@inn.qnx.com> …

In Windows, a return result of 0 from the socket recv() calls means that
the other end has shutdown its socket. An exception to this is if you
call
recv() with a parameter requesting 0 bytes (yes, I had a silly loop and
did
this). In this case there is no error and work can be continued with the
socket.

It does not explicitly say that the QNX sockets have the same behavior.
I have been getting some zeroes, and I am not sure if this means that the
connection is gone.

Does anybody know?


0 means there is no data in the received buffer, it’s not an error.


Robert Kindred

\

“John Nagle” <nagle@overbot.com> wrote in message
news:clupac$40m$1@inn.qnx.com

The QNX help page for “recv” says “if no messages are available
at the socket, the receive call waits for a
message to arrive, unless the socket is nonblocking – see ioctl() – in
which case -1 is returned and the external variable errno is set to
EWOULDBLOCK.”

But, in fact, what seems to happen if no data is available is that
you get a normal return with 0 bytes, at least some of the time.
At least in 6.21.

Very strange behavior indeed. I posted this question to
technical support, and got this response:


They should be getting a return of zero if the other side has closed. If

they are getting EAGAIN (EWOULDBLOCK), it suggests that the socket is

configured to be non-blocking. Is that the case?

Getting EWOULDBLOCK on an

ESTABLISHED socket is the expected behavior if the socket was in

non-blocking mode and there was no data to read. If the socket was in

blocking mode, the recv() call would block waiting for more data until the

socket was closed remotely at which point the recv() call would return 0.

An important issue here is that the QNX host shows the socket in an

ESTABLISHED state, while the Windows host does not display the socket

anymore. This implies that the two hosts lost conectivity for a long

period of time as the Windows host should have sent a FIN, received

nothing, applied timeouts and eventually closed the socket on its end. As

the QNX host is still in the ESTABLISHED state, it does not know that the

other host went away. If the QNX application is always receiving messages,

and never sending messages unless it received a message, then it will not

detect the other host has went away. They could apply an application

timeout if they expect to receive messages at a certain rate, or they

could apply the socket option KEEPALIVE to poll the remote host to make

sure it is still there.


A friend of mine tells me that the TCP stack in QNX is taken from Berkely,
and so should exhibit similar behavior. Since my case is client software,
I am using blocking sockets, and I am not using the select call. Maybe I
am running into problems since I am off the beaten path? One thing that I
have not tried yet is to enable KEEPALIVE’s, as suggested.

Since you don’t normally call “recv” until you get a success return
from “select”, the no-data case isn’t usually exercised.

John Nagle

Mario Charest wrote:
“Robert Kindred” <> RKindred@SwRI.edu> > wrote in message
news:ck3i07$fk5$> 1@inn.qnx.com> …

In Windows, a return result of 0 from the socket recv() calls means
that
the other end has shutdown its socket. An exception to this is if you

[]
Robert Kindred