Application of the Form Machine to Program Protocols

The Protocol Manager mentioned in NWG/RFC #80 needs several interesting features that are properties of the above Form Machine.

In certain instances during a protocol dialog it might be acceptable to get either an accept on connection A or an allocation on connect B, that is, the order is sometimes unimportant. The defined procedure for applying rules allows for order independence.

A logger might send us a socket number embedded in a regular message -- the socket number is intended to be the first of a contiguous set of sockets that we can use to establish connections with some program. We wish to extract the socket number field from the regular message, perhaps convert it to another format, and add to it to get the additional socket names. As a result of the regular message we wish to emit several INIT system calls that include the socket numbers that we have computed. The value operator and the arithmetic operators of the Form Machine can do this.

A third property of the Form Machine that is applicable to protocols is inter- and intra-rule binding to resolve context sensitive information. In general we wish rules to be order independent but in certain cases we wish to impose an ordering. Using the logger in NWG/RFC #66 as an example, the close that is sent by the logger can have two different meanings depending upon its context. If the close is sent before the regular message containing the socket number then it means call refused. If the regular message precedes the close then the call is accepted. Since the close has contextual meaning, we must bind it to the regular message to avoid introducing IF and THEN into the Form Machine language.

Assume for a moment that we can express system calls in Form Machine notation. (The notation below is for illustration only and is not part of the Form Machine language.) We have two ways to bind the regular message to the close. By intra-rule binding we insist that the close be preceded by a regular message.

      Reg. Msg , Close ->

Now assume for a moment that the remote party must have an echo after each transmission. Since we must emit an echo after receiving the regular message and before the close is sent, then we must use inter-rule binding. This can be accomplished with the programming variable. It is assigned a value when the regular message is received and the value is tested when the close is received.

      Reg. Msg -> Echo , ([lambda]+1)

      Close, ([lambda]=1) ->

To illustrate inter-rule binding via the programming variable the connection protocol in NWG/RFC #66 could be represented by passing the following form to a protocol manager. (The notation below is for illustration only and is not part of the Form Machine language).

      1. ->INIT(parameters) , ([alpha]<-0)

Send an INIT(RTS).

      2.  INIT(parameters) -> ALLOCATE(parameters)

Send an allocate in response to the connection completion (an STR received).

      3.  Reg. Msg (parameters) -> ([alpha]<-1)

When the messages bearing link numbers is received, set an internal indicator. (The extraction of the link is not illustrated.)

      4.  CLOSE(parameters),([alpha]=1) ->
                             INIT(parameters),INIT(parameters)

When the close is received following the regular message [2] is checked to see that the regular message was received before establishing the duplex connection. If the close is received with no regular message preceding it (call refused) the form will fail (since no rules is satisfied).

This protocol can be handled via a single form containing four replacement rules. We have examined similar representations for more complex protocol sequences. Such protocol sequences, stored by name, are an asset to the user; he can request a predefined sequence to be executed automatically.