Re: [8023-POEP] Power management discussions during ad-hoc
Geoff and others who have replied offline,
You are absolutely correct. Stateless mechanisms are inherently more
robust in noisy channels - that is their main advantage. However,
stateful "cheating" with stateless mechanisms leads to subtle and
annoying bugs that are notoriously difficult to diagnose. That's why
stateless mechanisms should only be used where the intention is
stateless behavior.
Stateful protocols are much more flexible but must be designed for
robustness. In particular, the handshake must be sure and the error
behavior must be properly defined (including the out-of-sync and lost
partner cases that Geoff points out). As part of this, my intention is
to propose a very, very simple state machine with a three-way handshake
mechanism (i.e. "I want to change" - "go ahead and change" - "thank you,
I've changed"). By making the state machines extremely simple we can
outweigh the increased complexity of stateful design.
Hugh.
Geoff Thompson wrote:
> Hugh-
>
> My comments would be along the line of general comments of stateful
> vs. stateless.
>
> Distributed state machines where the various pieces are connected by a
> noisy communications channel are a problem.
>
> Duplicate state machines where the multiple pieces are connected by a
> noisy communications channel need to have a means to cope with:
> - detecting when they get out of sync
> - an established benign behavior to revert to when they get
> out of sync
> - an established benign behavior to revert to when
> communication fails
> (and the assumption has to be that the remote went away)
> The fact that we can generally assume that the channel is not very
> noisy doesn't really help much. You can't depend on it enough.
>
> None of these considerations, in a general sense, go away with
> stateless design.
> However, I think it is a little easier to do.
>
> I hope this helps, at least to spark the discussion.
>
> Geoff
>