Hi.
As promised I had a look at the XORP implementation of the BGP state machine.
It is actually a straightforward implementation of a state machine class
such as i have seen many times before.
A class is defined to hold all the state associated with each instance of
the state machine. In BGP this is tied to a peer and a socket connection,
but that wouldn't be the case exactly in GIMPS.
The class data contains references for all the associated timers as well as
the actual state variable.
The possible states and events are defined as enumerated types and there is
an event handler routine for each possible event.. these routines are then
called in line from appropriate parts of the code. The incoming messages
are handled by linking a callback to the socket that receives them...
likewise timers are created when the peer enters the correct state and the
timer events are linked back to the state machine by callbacks.
The actions on state transition are handled by a central set_state
transition routine: the routine is relatively simple in this case because
there are relatively few transitions.
The structure would (IMHO) work pretty well for GIMPS and would not
require much effort.. The main difference is that the socket message
processing would have to be separated and a look up done to determine the
right state machine instance to activate depending on the traffic
descriptor, rther then the sockets being tied one to one to the peer and
state machine.
The main problem for the future is handling the source/middle/end
distinction between state machines nicely because each node is quite likely
to have some of each. However this is just an opportunity for neat design
rather than a serious issue.
I am checking the state machine diagrams next and will make a start on some
implementation shortly.
Regards,
Elwyn