I have heard of HTTP keep-alive but for now I want to open a socket connection with a remote server.
Now will this socket connection remain open forever or is there a timeout limit associated with it similar to HTTP keep-alive?
views:
2179answers:
4
+3
A:
TCP sockets remain open till they are closed.
That said, it's very difficult to detect a broken connection (broken, as in a router died, etc, as opposed to closed) without actually sending data, so most applications do some sort of ping/pong reaction every so often just to make sure the connection is still actually alive.
Matthew Scharley
2009-09-26 02:14:34
Okay so the implementation should make sure to check at regular interval that the connection is dead or alive, right?
Kevin Boyd
2009-09-26 02:15:44
It's a good idea. You don't *have* to, but if you don't, then you may not detect a broken link till someone actually wants to do something. Which may or may not be a good thing (or may or may not matter), depending on what you're actually trying to achieve.
Matthew Scharley
2009-09-26 02:28:52
+6
A:
You are looking for the SO_KEEPALIVE socket option.
The Java Socket API exposes "keep-alive" to applications via the setKeepAlive and getKeepAlive methods.
EDIT: SO_KEEPALIVE is implemented in the OS network protocol stacks without sending any "real" data. The keep-alive interval is operating system dependent, and may be tuneable via a kernel parameter.
Since no data is sent, SO_KEEPALIVE can only test the liveness of the network connection, not the liveness of the service that the socket is connected to. To test the latter, you need to implement something that involves sending messages to the server and getting a response.
Stephen C
2009-09-26 02:24:27
If I a setKeepAlive(true); what would be the interval?... also will Java keep sending keep-alive messages at the default interval or will I have to do it programatically?
Kevin Boyd
2009-09-26 02:30:11
http://www.unixguide.net/network/socketfaq/4.7.shtml Has a description of SO_KEEPALIVE. It's not so much what the OP wanted, though it *is* a protocol based option to what I suggested... though, once every two hours won't do much for applications.
Matthew Scharley
2009-09-26 02:31:06
+2
A:
If you're behind a masquerading NAT (as most home users are these days), there is a limited pool of external ports, and these must be shared among the TCP connections. Therefore masquerading NATs tend to assume a connection has been terminated if no data has been sent for a certain time period.
This and other such issues (anywhere in between the two endpoints) can mean the connection will no longer "work" if you try to send data after a reasonble idle period. However, you may not discover this until you try to send data.
Using keepalives both reduces the chance of the connection being interrupted somewhere down the line, and also lets you find out about a broken connection sooner.
Artelius
2009-09-26 02:32:49
Ah! you add a good point here, that is you have to also consider the in-between things that might hinder the operation of a connection such as NAT routers etc...
Kevin Boyd
2009-09-26 03:01:12
This is a good point, and a good reminder that there's more to keep in mind than just what we're directly implementing ourselves. Also, Lemmings!!
Matthew Scharley
2009-09-26 03:13:06
Note that p2p file sharing both chews up a lot of ports and produces a lot of zombie connections, making it more likely that the NAT will need to prune idle connections.
Artelius
2009-09-26 08:06:57
Not necessarily, a TCP connection is identified by 4 elements: src ip, src port, dest ip, dest port. So you can reuse the same external (source) port as long as the destination ip is different.
Dan Berindei
2010-01-11 14:42:28
Oh yeah, you're right. I think the real reason is that NATs have a fixed size table of open connections, due to memory constraints and lookup time.
Artelius
2010-01-14 21:39:54
+3
A:
TCP keepalive and HTTP keepalive are very different concepts. In TCP, the keepalive is the administrative packet sent to detect stale connection. In HTTP, keepalive means the persistent connection state.
This is from TCP specification,
Keep-alive packets MUST only be sent when no data or acknowledgement packets have been received for the connection within an interval. This interval MUST be configurable and MUST default to no less than two hours.
As you can see, the default TCP keepalive interval is too long for most applications. You might have to add keepalive in your application protocol.
ZZ Coder
2009-09-26 02:52:51
You can modify the TCP keepalive interval to suit your application. E.g. http://msdn.microsoft.com/en-us/library/dd877220%28VS.85%29.aspx
Dan Berindei
2010-01-11 14:46:20