[cap-talk] impossibility of reliable channels?

Jed Donnelley jed at nersc.gov
Fri Feb 3 14:26:51 EST 2006


At 10:35 AM 2/3/2006, David Wagner wrote:
>Ian G <iang at systemics.com> writes:
> >I would say that the usefulness of the result is to show that there are
> >no reliable channels.  Full stop.
>
>Nope, that's wrong.  The argument says that *if* you use an unreliable
>channel, then such-and-such can happen.  Note the difference between
>a premise and a conclusion.  The question of whether reliable channels
>exist or not is a question of physics, not of algorithms, and this proof
>does not purport to show that reliable channels cannot exist.

Hmmm.  It seems to me the above disagreement may be a matter of
terminology/levels.  I think what Ian is saying that in the face of packet
losses on a network, there is no way to build a completely reliable
virtual circuit/channel (where both ends know exactly what happened)
on top of it.  David seems agree.  However, David argues that
one can construct quite reliable hardware channels (despite
quantum mechanical uncertainty ;-) by effectively using the
materials of the hardware channel.  This is also true.

Since most of my communication world is built on network components
like those of the Internet where packet losses are a part of life (most
often from congestion or other human effects rather than from
intermittent hardware channel failures), I agree with Ian's statement.
In the (to me) rare case where I happen to be dealing directly
over a very reliable hardware channel - well, I'm just as happy using
my protocols that are designed to work in the face of unreliable
channels.  In practice they add relatively little overhead and
this reliable channel might just prove not so reliable some
day (e.g. when it is disconnected for some reason).  This
generally means building in mechanisms for limited retrying,
timeouts, and recovery from failures in any protocol.
Always wise in my opinion.  I'm sure Ian G and I expect David W
agree.

--Jed http://www.webstart.com/jed/ 



More information about the cap-talk mailing list