> 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.

The whole point of TCP (vs IP alone, or UDP) is to establish
reliable end-to-end communication over unreliable underlying links.
If a packet is corrupted or lost, it gets resent.  If a route goes
down, and an alternate is available, TCP will -- eventually -- find
it and recover.  If the last (or only) route goes down, TCP will in
principle wait indefinitely for a route to become available, whether
by reestablishment of the original or provision of an alternative.

So you are correct that a receiver can't tell the difference
between a loss of connectivity and the sender having crashed,
however the situation is entirely symmetric: the sender can't tell
the difference either.  It all gets sorted out when communication
is reestablished; at that point traffic will resume (if the link
had been down) or the uncrashed end will get a connection reset
(if its peer had crashed).

The practice of sending keep-alive packets simply converts a
temporary (thus potentially recoverable) communication loss
into what amounts to an unrecoverable crash of whichever end
gets impatient first.
_______________________________________________
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"

Reply via email to