2

If a TCP server establishes a TCP connection with a TCP client and the TCP client never sends any packet to the server.

I roughly know firewalls near the TCP server may send an RST to it. Or there is a keep-alive timeout which forces the TCP connection to end. But I do not know exactly what will happen？ Can anyone explain a bit?

Is it possible to maintain this TCP connection unless I want it to end?

I just hope the TCP server can keep this TCP connection on its TCP stack. But I do not want the TCP client to be involved. I do not want it to send KEEP-ALIVE. I do not want any other third-party entity involved. I just hope that when I am writing the TCP server's source code, the source code can manage to maintain the TCP connection.

Pro Codeing
  • 15
  • 6
misteryes
  • 2,895
  • 13
  • 41
  • 49

1 Answers1

0

Unless a FIN or RST is sent, the only other way standard TCP knows if the other side has quit, or gone away, is an expiring timeout.

This is really the best you can do by design if you are making the least amount of assumptions of the "other side" as possible, and your only connection to this "other side" is a single network interface.

An event lower on the OSI model may cause the OS to terminate the connection on its own, or provide information that could tell the client to pretty much just give up, such as removal of the network adapter in question, or the link state changing to being disconnected. This doesn't have to happen, though.

The general solution is to send periodic messages with no meaningful data, called a keepalive, through the connection. TCP supports this, but you can do it on the application layer as well.

  • FileZilla can be set to send keepalive messages. You can see it send commands that don't do anything useful, but are just issued to throw something down the pipe and keep it "busy."
  • PuTTY, for example, has keepalive options as well.
  • You can also set keepalive options on the server as well, but it's usually better to set that on the SSH client.
  • Many routing protocols send keepalives on the application layer to verify other routes are working and available, BGP, for one.
  • TCP also supports keepalive messages natively as well, they are basically null Ethernet packets sent every so often to verify the connection. This tldp.org article explains well.
LawrenceC
  • 73,030
  • 15
  • 129
  • 214
  • At first sight, I don't understand each solution clear.I just hope the TCP server can keep this TCP connection on its TCP stack. But I don't want the TCP client to be involved, I don't want it to send KEEP-ALIVE. I don't want any other third-party entity involved. I just hope that when I'm writing the source codes of TCP server, the source codes can manage to maintain the TCP connection. – misteryes May 30 '13 at 11:52
  • @misteryes If the client is not involved, how do you tell the diffrence between a client who has not sent a packet in two days and a client who had a power outage and the program is no longer running? If your server never culls dropped connections you will run in to problems quickly with running out of resources. – Scott Chamberlain May 30 '13 at 13:28
  • @Scott Chamberlain I have have another condition, when this condition is true, I my source code will call `close(sockfd)` to end it. I just want to keep the connection active on the server side when that condition is false. – misteryes May 30 '13 at 16:30
  • Then this is a question for StackOverflow, tell them what socket library you are using and they can help you. However, know that yo uare going to run in to issues like ultrasawblade mentioned, computers between your sever code and the client may close the connection down, even if the server is still listening. Once that happens the connection will appear as a new connection due to things like the client's NAT router choosing a new random source port for it's connection. – Scott Chamberlain May 30 '13 at 16:36
  • @Scott Chamberlain I don't care how the client react. I just want to keep the connection on the server side – misteryes May 30 '13 at 18:34
  • @misteryes: Then you must send something through that connection, to keep it alive. And the other side has to respond, to prove to you it is there. There is no other way. – LawrenceC May 31 '13 at 01:43
  • why? are there anything that make the tcp tear down if I filter the RST? – misteryes May 31 '13 at 11:56