TCP Connection Never Terminates

[Judy Traynor]

Hello,

We are implementing a Primary / Alternate Server system in C++ on HPUX-11. The two servers are connected via TCP. As part of our failover requirments we are supposed to be able to detect and recover from a broken ethernet cable. When we pull the cable on one of the machines effectively cutting it off from the network, we expected that our TCP socket connection would break. This is not what is happening. Unix "send" calls over the connection continue to return a success status. A unix "Receive" call continues to wait for something. A "netstat -a" command still shows the connection as being established. According to our system Admin, the network tuneables are set so that keep-alive should not be more than 6 seconds. What really puzzles me is the success returned from "Send". Any ideas what could be wrong?

[Robert-Jan Goossens]

Hi,

Take a look at Eran remarks(doc)

Robert-Jan.

[John Poff]

Hi,

I'm curious. It sounds like you are trying to duplicate some of the LAN failover switching abilities in MC/ServiceGuard. Are you writing software to handle a failover? Is MC/SG not an option? I hate to see you have to re-invent the wheel when MC/SG does such a good job of handling those issues already.


I think Robert-Jan was referring to the doc in this thread:

http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0xda90663ce855d511abcd0090277a778c,00.html


JP

[Judy Traynor]

We're writing an application for the Navy, and MC Service Guard was never spec'd in the initial proposal. So it won't be going in there. The government is very picky about their contractors following a contract exactly.

[Robert-Jan Goossens]

Thanks John, made a slide mistake or was it netscape (:>)

Kind regards,

Robert-Jan.

[Judy Traynor]

Robert-Jan,

The info in that doc looks interesting. I will compare
the info in there against what the settings are on our
network.

Thanks.

[rick jones]

Send calls after a cable disconnect will not "fail" until after the TCP connection has exhausted its retries for the data outstanding at the time of the cable disconnect. (or the first send after the cable disconnect if the connection was idle prior to the disconnect)

A recv() call will _never_ terminate unless...

The TCP connection was also trying to send data - in which case the maximum retransmissions limits will be reached.

or

The application has set SO_KEEPALIVE with setsockopt() - in which case TCP will periodically send a "are you there" segment when the connection is idle (no outstanding data from that end)

If an application has particular requirements for detecting connection failure, it would be best for the application to run its own keepalives and timouts.

ftp://ftp.cup.hp.com/dist/networking/briefs/annotated_ndd.txt