IMPLEMENTATION
Message Structure
Definition of States
Modular Design
A modular programming approach was used in our implementation. In so doing each
module had an independent function that aided in debugging and testing. Our four
main modules are called 'sotmod', 'sot_message', 'sot_signal' and 'dbase'.
The 'sotmod' module contains the major part of the logic for clustering by handling
the messages from the signalling channel in the appropriate manner. It also sets and
maintains the appropriate states in the protocol and is responsible for the initialisation
of the SOT implementation. Therefore it can be regarded as the module performs the
messaging part of the protocol.
The 'sot_message' module deals with creating messages and accessing the different
various bits of information in the message and performs the basic conversions
necessary for storing different data types into the signalling message structure.
The 'sot_signal' module creates and initialises a multicast channel to be used for
signalling. It also sends and receives data on this channel, formatting the necessary
parts of the message structure to network format.
The 'dbase' module initialises the history database and updates it each time a packet is
received. When the database is full this module shifts the top half of the data
downwards and re-initialises the top half to be used for incoming packets. It is also
responsible for retrieving the appropriate LBP from the database.
Implementation of the Hierarchical tree
In implementing the bottom-up design of the hierarchical tree a very naive scheme
was used for setting up the timers that determined how long a scheduled request or
response would wait before being sent. The time that a request is scheduled for before
it is actually sent is called the 'wait_time' and was calculated using the following
equation:
wait_time = (1/ distance to source) * maximum tree distance + random number
Initially the distance to source was measured as the single trip time to the source from
the receiver and was achieved using receiver reports. However, since the computer
clocks were severely skewed in the environment used, the distance to source was
configured into a file that was read in during initialisation of the protocol. The
maximum tree distance was factored into the equation so that the wait time was
sufficiently large enough to notice and measure the difference. This value was set to
fifty to complement the tree topologies that were used so as to ensure that the
wait_time was neither too large nor too small. The random number was added to help
prevent collisions and re-occurrences of them. This random number was set between
0 and 200 milliseconds. This method ensured that the wait_time for each request was
inversely proportional to the distance to the source and adheres to the requirements of
the bottom-up approach.
When a response is scheduled, the time that it waits before it is sent was calculated
using the following equation:
time = distance to requester/10
With this equation it can be seen that the response closest to the requester would be
sent first ensuring that the transcoder closest to the requester and thus the congested
link is chosen. When a potential transcoder sees a response it checks the distance of
it's own response and if the distance in the received response is closer, the potential
transcoder de-schedules its response. If however, other responses are sent as well, the
requester has a built functionality that chooses the closest transcoder. Again the value
of ten was used to simplify the testing in the environment used and in reality some
other factor may be used.
Since both responses and requests are de-scheduled when another is observed with
better distance (closer to requester or further from source respectively), this helps
reduce the number of messages on the signalling channel, ensuring a fairly efficient
protocol. The trade off to this is that some extra processing is required by each node
when they receive request and response messages. However, this is justified since
SOT is used when there is congestion and a protocol that does not add further
congestion would be more efficient and robust. The performance would be affected in
that the processing time would increase but the number of messages would be smaller.