Query-Node Routing State Machine: Detailed Processing Notes

Awaiting Response State

This is the initial state and is entered when the state machine is created by General Processing in response to a request to send a message for an unknown flow. No routing state for the remote node is stored at this point (as described in the specification), but some stored state is required to keep track of retransmitted Query messages.

On entering this state a Query message is passed to DMode Message Handling for transmission to the remote node and the NoResponse, Inactive, RefreshQNode and ExpireQNode timers are started (setQNodeLifeTimers & setNoResponseTimer actions). The NoResponse timer is used to resend Query messages in the event that a Response is not received from the remote node. This timer generates tg_NoResponse events according to a binary exponential backoff algorithm.

The routing state entry remains in this state until either a Response is received (generating a tg_Response_Rcvd event) or the ExpireQNode timer expires (generating a to_Expire_QNode event). If a Response is received then the Established state is entered and a new MA is created if necessary. If a Confirm is requested by the remote node then it is generated and passed to an appropriate MA or DMode Message Handling at this point. If no Response is received before the to_Expire_QNode event, the routing state entry is destroyed and an error is indicated to the NSLP.

If the NSLP attempts to send any messages using routing state associated with this state machine while it is in this state, the messages are stored until the Established state is entered.

Established State

This state is entered when the identity of the remote node is established. On entering this state the full routing state is stored, the RefreshQNode and InactiveQNode timers are started and the ExpireQNode timer is reset.

The routing state generally stays in this state until a timeout occurs indicating that the routing state should be refreshed (to_Refresh_QNode). At this point a Query is usually passed to the DMode Message Handling state machine and the routing state enters the Awaiting Refresh state.

Awaiting Refresh State

In this state the routing state is still stored, and messages may still be sent using this state machine, as in the Established state. The main difference is that the NoResponse timer is activated once again causing Query messages to be transmitted until either a Response is received or a to_Expire_QNode event occurs.
In the former case the routing state returns to the Established state. In the latter the routing state is destroyed.

State Machine Destruction

There are 3 events which may lead to the destruction of a Q-Node state machine: to_Expire_QNode, to_Inactive_QNode and er_MA_Destroyed. Any routing state stored by the state machine is deleted when the state machine is destroyed.

to_Expire_QNode events are generated by the ExpireQNode timer. This timer is reset at the same time as the RefreshQNode timer, whenever a Response is received from the remote node. The ExpireQNode timer generally has a significantly longer period than the RefreshQNode timer, allowing a Query to be retransmitted several times before the ExpireQNode timer expires. If the ExpireQNode timer is allowed to expire, a to_Expire_QNode event is generated and the state machine is destroyed.

to_Inactive_QNode events are generated by the InactiveQNode timer which is used to keep track of whether the state machine is still required by GIMPS. This timer is reset each time the state machine handles NSLP data, in either direction. If the timer expires, the state machine is considered to no longer be required and is therefore destroyed.

A er_MA_Destroyed event is generated when a MA is unexpectedly destroyed, usually due to a problem encountered by the local protocol stack the MA is using. If this happens any routing state stored by the state machine is likely to be invalid, so the Q-Node state machine must be destroyed.