[boost] Re: Inter-FSM protocol discussion

From: Andreas Huber (ah2003_at_[hidden])
Date: 2003-06-23 16:16:25

Chris,

Sorry for the long delay, I was swamped with other stuff.
The longer I think about your suggestions about FSM protocols the more do I
think that coded FSM protocol specifications are not worth the effort. Even
worse, I believe they will inevitably lead to code duplication. However,
since I don't understand all of what you said, I may well have overlooked
some important points.

Before I start, I'll try to define my understanding of a protocol:

*When* (timing and/or state) and *how* (effects) a particular entity will
react to what kind of input.

Please note:

- The general term "effects", which can be just about everything (modifying
an internal counter, flushing a buffer, calling a callback object, returning
a value, etc.).
- Sender and receiver entities were deliberately left out of the definition
because this would only complicate the matter without any benefit, IMO.
- Even more deliberately, the terms FSM (replaced with "entity") and event
(replaced with "input") were avoided. Replace "entity" with class or
function and you'll see that both define what I believe a protocol is.

The last note brings us to my point:

The interface and the implementation of an entity (function, class, FSM,
etc.) already define its protocol. There's no point in specifying the
*whole* protocol once more with more code as this would inevitably duplicate
some information, even if the specification is on a higher level. Granted,
asserts sometimes partly do exactly that, but never fully.

You mentioned concept checking between communicating state machines. IIUC,
you would want to define some kind of a channel between the two machines.
The channel would:

1. Anonymize, i.e ensure that there are no cyclic dependencies between the
two machines.
2. Check the type and maybe even the contents of events going through the
channel. That is, it checks that the channel protocol is not violated.

- I realize that it could sometimes be desirable to have support for 1,
especially if you want to have complete anonymization (the client does not
know the server and vice versa). However, as handcrafting this amounts to
only a couple of LOCs I doubt that it would be worth the effort.
- Either explicitly or implicitly, the participating state machines must
implement all of the checking done in the channel. Essentially the channel
would duplicate most of these checks. The only difference is that state
machines ignore "bad" events by default, while the channel would presumably
throw after detecting such an error. In my last project we needed exactly
such behavior (throwing of an exception if the receiving state machine fails
to consume a particular event). boost::fsm does not currently support this,
mainly because I'm still struggling to find a proper name for such an event.

Regards,

Andreas