On Sun, 22 Mar 2009, Yoshihiro Ota wrote:
On Fri, 20 Mar 2009, Yoshihiro Ota wrote:
1. With TCP connections, only sender side can detect some communication
issues passively if happened. By using two connections, you lost that
ability by your self. I agree on this one.
Could you expand a bit on this point? While the connection creation
process (usually) asymmetric, once the connection is built it's essentially
the same state machine on both sides of the connection, and socket
semantics with respect to the state machine are effectively identical.
Application on both sides should be able to detect disconnect, monitor
connection state using TCP_INFO, etc.
What I meant was that there were cases when a receiver could not tell
weather no data was coming or communication was interrupted. Once
connection is established, a route is available between a server and a
client. Let's say this route is broken for some reasons, i.e. someone
unplugged a cable or a firewall started dropping or rejecting between these
server and client, a sender may not notice as soon as it happens but at
least, a sender knows a massages was not delivered right. On the other
hand, receiver side does not have any idea that a message delivery failure
has happened at all or for a while unless using heartbeat messages in upper
layer. KEEP_ALIVE option seems to be implementation dependent such that you
cannot assure TCP connection availability for every minute.
This is generally considered a robustness property rather than a fragility
issue, but yes: if you need a liveliness property for idle connections with
TCP, it's something you have to implement at the application layer, and many
protocols indeed do this. I don't see that this is an argument for using two
TCP connections as opposed to one, however. If you're interested in
alternative protocols, however, SCTP allows a number of these protocol
behaviors to be modified, and includes support for a heartbeat.
Robert N M Watson
Computer Laboratory
University of Cambridge
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
