Question

I have a situation here. I have a redundant TCP server setup which takes an input and then throws lots of packets forever. While reading them, I am also trying to keep up with the server’s state from TCP client by doing a send on the socket.
But my servers are redundant sharing a Virtual IP. So if server1 goes down, server2 starts up and uses the same VIP (At all point of time VIP is up and running). So my send technique is able to find out this situation.
My server2 waits for the client’s input, but since send is not doing the job I expect it to do, I am not able to send the input again.

  int status = ::send ( m_sock, s.c_str(), s.size(), MSG_NOSIGNAL );
  if ( status == -1 )
    {
      return false;
    }
  else
    {
      return true;
    }

Can someone help how I can figure out this kind of failover?

Answer 1

Okay, piecing things together, I am starting to get a picture here.

• The OP is using some kind of failover in which the remote server doesn’t actually keep track of the state

The reason you’re not getting EPIPE from the send is that things happen this way:

• You send data. send unblocks and segments start travelling
• The remote server receives data. “Who is this guy ? RST!”
• You get the RST but send has already returned. The connection is torn but there is no way to inform you of it (it doesn’t have any out-of-band mechanism)
• Do another send

In conclusion, if you want to test if a connection is still alive:

• send data
• Wait a bit (RTT and such)
• send again

If you don’t get EPIPE after the second send, the connection is still up. Another scheme:

• send data that should be interpreted as “Say something if you’re alive!”
• Wait a bit
• If after the timeout you haven’t received confirmation, the connection is dead