Messaging Association State Machine: Detailed Processing Notes

Awaiting Connection State

On creation an MA may either listen for an incoming connection or attempt to connect to a remote node. In either case the MA stores any state required to create the connection and enters the Awaiting Connection state.

If the MA is listening for a connection, the NoConn timer is started. This generates a to_No_Conn event if a connection is not established within a set time period. If a to_No_Conn event occurs then the MA is destroyed. Likewise, if the connection attempt fails (indicated to the MA via an er_Conn_Err event) the MA is destroyed.

If a connection is successfully established the MA enters the Connected state.

Connected State

This state indicates that a connection has been established to the remote node. Messages passed to the message association for transmission are sent over the connection immediately . Any messages received from remote nodes are passed immediately to the General Processing state machine for further processing. The MA stays in this state until either the connection is broken or an inactive timeout occurs. In either case the MA is destroyed.

Security Information

Security is controlled from the NSLP by passing Security Information (SecInfo) between itself and GIMPS. The format of the SecInfo is implementation specific, but is likely to include:
At its simplest the SecInfo can be treated by the NSLP as a simple handle which can be obtained from recvMessage or the SecurityProtocolAttributesRequest callback and passed back to GIMPS in calls to SendMessage to ensure that messages are always sent to the same node using the same security measures. However, the NSLP can also query the information contained in the SecInfo to allow it to decide whether to abort a message exchange.

At the sending node, there are three options for the NSLP when calling sendMessage. Supply a SecHandle, supply a stored SecInfo object, supply nothing.
If a SecHandle object is supplied to sendMessage it must be stored by GIMPS until a Response is received from the remote node. The SecHandle is then passed to the MA when it is created. If the MA requires security information from the NSLP during connection setup, it calls a SecurityProtocolAttributesRequest callback, supplied by the NSLP, which contains the SecHandle and a SecInfo object containing information about the connection.

The NSLP may store this SecInfo from the callback to pass to subsequent calls to sendMessage. If a SecInfo object is supplied to sendMessage GIMPS checks that this matches the SecInfo of the MA for this flow / NSLP. If it does then the message can be sent over the MA, otherwise a message delivery error is given back to the NSLP.

If neither a SecInfo nor a SecHandle is passed to sendMessage GIMPS relies on local policy to set up an MA.

At the receiving node when a message is received over a secure connection the MA creates a SecInfo object and passes it to General Processing along with the message. These are in turn passed to the appropriate R-Node or Q-Node state machine which passes the SecInfo object with the message to the NSLP in the recvMessage API call. Again the SecInfo object may be stored and/or inspected by the NSLP. If the NSLP is happy with the SecInfo (or doesn’t care about it), recvMessage returns OK; otherwise an error is returned and the Q-Node or R-Node state machine may be destroyed.