[boost] Re: Inter-FSM protocol discussion

From: Chris Russell (cdr_at_[hidden])
Date: 2003-06-09 01:47:39

Hi Scott,

point well taken. I think we're talking at different levels in the great
abstraction foodchain. When you speak of protocols, you're talking about a
specification (like one published by the ITU) that you need to implement. If
I understand you correctly, you're saying that in practice you don't
actually implement the entire specification for all targets under all
circumstances. So in code you might have alternate implementations of FSM's
that each more-or-less implement parts of the specification, and by
extension their event signaling semantics may differ?

What I'm talking about is a mechanism for formally describing the
event/signaling interaction semantics between specific sets of FSM's - a
specific object-level protocol if you will. By my way of thinking then, for
you to go off and use this to implement, for example, an ITU telco protocol
for different targets (you cite the example of four different ITU protocol
implementations on four different hardware platforms) would require
alternate FSM implementations (and by extension alternate inter-FSM
object-level event signaling protocols) be defined for each target platform.
Worst case the implementations are completely orthogonal in which case this
idea would only help you on a per-target basis and that's really the limit
of the scope of what I'm talking about.

The whole business of doing high-level concept checking on mappings between
sets of objects is something I'm struggling with in another context right
now so it's useful to try to explain this stuff. Does this make more sense
now knowing that I'm talking at the level of abstraction of specific FSM's
and specific event/signaling protocols and not the more general full-blown
ITU style protocol? Sorry for the overloading, but I can't think of a better
way to describe it.

- Chris

"Scott Woods" <scottw_at_[hidden]> wrote in message
news:00d001c32e43$1a18df30$6104a8c0_at_Biffa...
> > "A category is given by two pieces of data: a class of objects and, for
> any
> > two objects X and Y, a set of morphisms from X to Y."
> >
> > What I was trying to suggest is that the objects in the category are
> FSM's,
> > and the set of morphisms defined for any two FSM's X and Y is a concept
> that
> > needs to be checked. Speaking as a layman, and not a discrete math
> theorist,
> > at first glimpse it would seem reasonable to think that the various
> flavors
> > of morphism might provide us with a nomenclature for describing the
set(s)
> > of inter-FSM event exchanges that a protocol could legally define
without
> > violating the semantics of any of the FSM objects in the category.
> >
>
> Hi Chris,
> Interesting. With a minimal understanding of discrete math theory (read
> zip) am concerned that I am about to say something stupid but did have 2
> to offer anyway.
>
> 1) With low uptake of FSM approach to coding - adding grouping and
> *morphing?
> Think I can see the same light and with a childhood fear of the dark would
> probably stumble in the same direction. The end of the tunnel could be a
> lonely
> place though;-)
> 2) Having worked on multiple implementations of several protocols one
> (painfully)
> delayed revelation went something like this. If you are required to
> implement Q.931
> on 4 hardware devices from 4 different vendors then you will produce 4
> distinct
> implementations. Targeting a set of common semantics is somewhat "flawed".
> In
> FSM terms an implementation of a protocol may have some transitions
missing.
> In practice there are specifics about a device or even the implementation
by
> the
> telco (yep, implementations of ITU standards on PSTNs vary) that mean a
full
> implementation is impossible. Have you ever dealt with minutely varying
> behaviours
> of mail servers (all fully POP3 or IMAP4 conformant)? Anyhow my point is;
> with
> your goal of defining permissible semantics, will there be the latitude to
> cope with
> previously described circumstances?
>
> SW
>
>
>
>
> _______________________________________________
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>