site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com On Nov 4, 2006, at 10:15 AM, Michael Ledford wrote: Hello, I really recommend: Unix Network Programming, Vol. 1: The Sockets Networking API W. Richard Stevens Addison-Wesley Professional ISBN: 0131411551 The places this doesn't hold true are: (1) Some place along the path, you've firewalled off ARP packets, OR - -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... 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. 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. (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. This email sent to site_archiver@lists.apple.com