Chapter 1

State Meaning
responses are handled in waiting state.
Here are the allowable states, and all allowable transitions between them (except reset
transitions, which have been omitted for clarity, but which are possible from any state to
blank) (see Figure A3.9).
Figure A3.9
RGCP states correspond precisely to underlying GSDP states, with the distinction that
GSDP's bound state is divided into two major states, requesting and waiting, that correspond
to whether it's this partner's turn to 'talk' or not. That's natural: this is precisely what a
conversation protocol is all about. The additional responding state is a brief transition state
between waiting and requesting.
All these states may be of arbitrary duration, except responding,which must complete in the
duration of a single synchronous function call. This implies that an RGCP response should
be a response to the request that contains information about the result of the other partner's
move – not a responding move, which would take arbitrary time.
The following state transitions are possible:
� Blank to initiating or listening: similar to GSDP
� Listening or initiating to blank, by a simple reset (omitted from the diagram for clarity)
� Responding, requesting or waiting to blank, by a terminate that's either called through
this partner's API, or received from the other partner as a request (omitted from the
diagram for clarity)
� Listening to requesting, by handling an initiate request (the responding state that you
might expect is handled internally by the RGCP stack)
� Initiating to responding, by receiving an initiate response and handling the incoming
request
� Waiting to responding, by receiving a response and handling the incoming request
� Responding to requesting, by completing the handling of an incoming request
� Requesting to waiting, by completing the formulation of a request and sending it.