“John Nagle” <firstname.lastname@example.org> wrote in message
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
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.
Mario Charest wrote:
“Robert Kindred” <> RKindred@SwRI.edu> > wrote in message
news:ck3i07$fk5$> email@example.com> …
In Windows, a return result of 0 from the socket recv() calls means
the other end has shutdown its socket. An exception to this is if you