Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

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
>