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