Re: TCP_KEEPALIVE
Re: TCP_KEEPALIVE
- Subject: Re: TCP_KEEPALIVE
- From: Terry Lambert <email@hidden>
- Date: Sun, 5 Nov 2006 13:35:46 -0800
On Nov 4, 2006, at 10:15 AM, Michael Ledford wrote:
Hello,
I have a network program that when used in the wild normally goes
through commercially available broadband routers. The problem as I'm
sure many people have had is after an unspecified and unconfigurable
amount of idle time the router closes the route causing any traffic
to fail.
Now I know we could implement a connection tickle in the application
level to be sent down the line but since OS X and darwin appeared to
support TCP_KEEPALIVE why not use what is already there? :-) The
only problem is that appears TCP_KEEPALIVE doesn't actually do
anything. So, I have cobbled together a sample socket client and
server app from others so I didn't have to write much code. :-) In
the client SO_KEEPALIVE is specified and TCP_KEEPALIVE is a
ridiculously low value. When using tcpdump I do not see any tickle
packets.
Keep-Alives are for servers, so if you are setting this on the connect
socket rather than the accept socket, then don't expect it to behave
like you want it to.
I really recommend:
Unix Network Programming, Vol. 1: The Sockets Networking API
W. Richard Stevens
Addison-Wesley Professional
ISBN: 0131411551
That said, if you change the code so that you are using it correctly,
and things still fail...
RFC compliant routers don't do this, unless you've turned on an RFC-
violating option, or they inherently violate RFC's; this is because
intermediate routers that aren't trying to "outsmart" something don't
know from connections, just packets, and their job is only to get a
packet from one interface to another, based on destination IP address
an ARP table entry.
The places this doesn't hold true are:
(1) Some place along the path, you've firewalled off ARP packets, OR
(2) You have a Cisco PiiX firewall or other stateful firewall that
tracks connection state, and has a connection timeout in order to
prevent a DOS attack via connection table overflow over time (in which
case, it's configurable, but you are likely either failing to
configure it, or you don't have rights to configure it).
In case #1, setting a Keep-Alive will help you, but realize that the
default Keep-Alive period mandated by RFC 1122 is *no less than 2
hours*. Any system participating in setting the Keep-Alive is
therefore free to ignore your requested interval, and crank it up to 2
hours, unless the requested interval is less than two hours. Also,
since implementing Keep-Alives is optional, they may choose not to
implement them at all. This includes any stateful firewall in the
middle dropping Keep-Alives that happen in under the RFC 122 interval.
In case #2, it's entirely possible that the firewall is filtering the
Keep-Alive packets out and discarding them, since instead of a simple
DOS, you could have a DOS with Keep-Alives set that gets around the
firewall hard timeout. The firewall is probably (no probably about
it, if it's a Cisco product) looking for actual data over the
connection, rather than simply spurious ACKs designed to keep the
connection up without necessarily doing any useful work.
Also note that in either case, the retry interval is such that, if you
are over the timeout window such that it sends Keep-Alives, and there
is no response in a set number of probe attempts, many systems will
drop the connection (see also RFC 2525, "Known TCP Implementation
Problems", section 2.9; I wasn't an editor, but I contributed to
2.15... 8-)).
-
Frankly, your best bet is an in-band tickle packet, but an even better
approach would probably be to redesign your communications channel so
that keeping a connection up for an ungodly amount of time with no
data flowing over it becomes unnecessary to its proper operation.
-- Terry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
| References: | |
| | >TCP_KEEPALIVE (From: Michael Ledford <email@hidden>) |