5

I've read that NAT routers "assume a connection has been terminated if no data has been sent for a certain time period."

I've also read that TCP keepalive packets usually shouldn't contain any data.

So my questions are:

  1. Are the above statements true?
  2. Do NAT routers consider empty TCP keepalive packets when reordering/cleaning their tables?

I'm asking this because I need a reliable connection between two endpoints where both of them have to be able to detect and react to connection problems. I know that I might just implement a keepalive mechanism myself but I want to know whether the TCP implementation could be used for that.

Community
  • 1
  • 1
Gerrit-K
  • 1,298
  • 2
  • 15
  • 30
  • It depends on the router. Forever living connections are an utopia; just make sure to detect broken connections and reconnect. – CodeCaster Dec 10 '13 at 15:14

1 Answers1

2

I do believe the second statement refers to payload (The shortest possible TCP/IP packet is 40 bytes long - 20 bytes for TCP header + 20 bytes for IPv4 header).

Regarding the first, here's a quote from RFC 2663:

End of session for TCP, UDP and others

The end of a TCP session is detected when FIN is acknowledged by both halves of the session or when either half receives a segment with the RST bit in TCP flags field. However, because it is impossible for a NAT device to know whether the packets it sees will actually be delivered to the destination [...] the NAT device cannot safely assume that the segments containing FINs or SYNs will be the last packets of the session [...] Consequently, a session can be assumed to have been terminated only after a period of 4 minutes subsequent to this detection. The need for this extended wait period is described in RFC 793 [Ref 7], which suggests a TIME-WAIT duration of 2 * MSL (Maximum Segment Lifetime) or 4 minutes.

Reference: https://www.rfc-editor.org/rfc/rfc2663

To my understanding, any packets that identifies a session would reset the TTL counter - but that depends heavily on implementation, since 'data' can be understood as 'packet' (minimum 40 bytes) or 'packet payload'. Nonetheless, @CodeCaster is spot-on; never assume that a connection is alive, make sure it is before sending (and, if possible and depending on criticality, acknowledge receipt.)

Community
  • 1
  • 1
OnoSendai
  • 3,960
  • 2
  • 22
  • 46
  • Thanks for the reference. Now I'm wondering why to use TCP keepalive anyway but I think that's another question ... – Gerrit-K Dec 10 '13 at 16:55
  • I think keep-alive's raison d'être lies on preventing unnecessary sequential handshakes - there's a cost associated to that, so if you plan on sending several small packets then keeping the connection alive is better than doing it all over again. – OnoSendai Dec 10 '13 at 17:41
  • Yes of course it is. What I meant was the *built-in* keepalive in comparison to a selfmade implementation that sends ping-pong-packets every x minutes/seconds ;) – Gerrit-K Dec 10 '13 at 18:54
  • 1
    Ah - I see your point now, blame it on lack of coffee. =) To tell the truth, on most socket implementations I worked on in the past that had even a wiff of QoS the first thing on the to-do list was a keep-alive mechanism. – OnoSendai Dec 10 '13 at 20:03