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

recv hanging

25 views
Skip to first unread message

yzg...@gmail.com

unread,
May 22, 2012, 9:32:41 AM5/22/12
to
Hi all, I've run my application into an issue with recv() hanging while the server already exited. recv() is not returning any data or error. More puzzling is that netstat shows on client side the connection in ESTABLISHED state while on server side netstat reports no such connection. Can someone shed some light or share any experience on this? Below is my system info. Many thanks.
$ uname -rv
2.6.18-194.el5 #1 SMP Fri Apr 2 14:58:14 EDT 2010

Rick Jones

unread,
May 22, 2012, 2:00:42 PM5/22/12
to
yzg...@gmail.com wrote:
> Hi all, I've run my application into an issue with recv() hanging
> while the server already exited. recv() is not returning any data or
> error. More puzzling is that netstat shows on client side the
> connection in ESTABLISHED state while on server side netstat reports
> no such connection. Can someone shed some light or share any
> experience on this? Below is my system info. Many thanks.

If the server side manages to "go away" without the client TCP seeing
it happen then you can indeed remain in a recv() call forever. For
example, if the server simply crashed, or if the server application
closed and the TCP FIN segmen and its retransmission was not received
by the client TCP.

TCP by default only runs timers when it is actively transmitting data
to the remote, so if there is no data still being transmitted to the
server, there are no timers running and so the recv() can stay there
forever.

There are a number of possible solutions:

1) Mark the socket non-blocking and use select()/poll()/epoll() with a
timeout that matches what your application requires.

2) Use setsockopt() to set SO_RCVTIMEO if all the stacks on which you
want your application to run support it.

3) Set SO_KEEPALIVE to cause TCP keepalives to be enabled. This will
cause TCP to send keepalive probes and so be able to detect
(eventually, by default it won't start probing for two hours) the
inability to reach the remote system.

I believe this topic is covered in various texts such as Stevens,
Fenner and Rudoff's "Unix Network Programming" and the works of
William Stallings among others.

rick jones
--
firebug n, the idiot who tosses a lit cigarette out his car window
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
0 new messages