The different RSVP states

The processing of RSVP messages is closely linked to the modification of the different states of the RSVP process. Therefore, the implementation of the processing of the messages and of the RSVP states were made at the same time. The path state was the first state implemented. Then I had to implement the reservation state.

In order to control the concurrency, synchronisation mechanisms have been implemented in a parent class called SynchronizedState. PathState, ResvState and TrafficControlState all derive from this class. Concurrency control is achieved thanks to a semaphore for each state. When a message is received and processed, the parser waits for the semaphores (using getMutex), and releases them when it has finished (using releaseMutex). The module dealing with the time-outs will do the same periodically.

Basically, those states are structures in which state blocks are stored. Again, path state blocks and reservation state blocks are similar because they both have a timer in order to provide a mechanism to support ``soft'' state. These mechanisms have been implemented in a class called StateBlock, and PathStateBlock and ResvStateBlock are its subclasses. The timer is set to a time in the future indicating when the state block will expire.

The traffic control state does not need this timer feature since all the changes are made via calls to the Traffic Control module further to changes made to the path or reservation states. The TraffiControlState class is shown in appendix .

The state block classes provide different facilities. Methods have been implemented to build a new state block easily, query certain fields, send refresh messages and display the contents.

An object which contains the three different states is used, called RsvpState. It contains code for the initialisation of the states.