This sounds like the same problem you already posted about.
If the select() returns when the other end is repowered, you
must have had something in the send Q. The stack is using
retries to send it and will give up after approx. 9 minutes.
If you reboot the other end before that, it will come up
with no knowledge of the connection and return a RST segment
to one of the retries which in turn causes the select() to
fail (quicker). If you never try to send but are using
select() on read, you could potentially block forever. Common
ways around this are application level heartbeats, SO_KEEPALIVE
If you don’t like the timeouts of the protocol, you can
specify a timeout as the last argument to the select().
ran zhang <email@example.com> wrote:
: My server program hangs if the client side lost power or network cable is
: I try to use select() to detect the socket state, but it wouln’t process any
: as soon as client is terminated due to power lost or network cable
: unplugged, and
: then as soon as client got power back on, select() is able to tel me that
: is bad…
: What Do I need to do so my server program keep running? I isolated
: the problem that the server program isn’t hanging on any function calls,
: it just wouldn’t process any codes…