Previous: Packetisation
Up: What the codec controller actually does
Previous Page: Packetisation
Next Page: Running it all

Implementation

In order to test and develop the software to implement the codec controller, the separate modules shown in figure 2 were all developed individually, and were originally separate UNIX processes which communicated through pipes. This modular approach makes testing and development simple, but the pipes introduce unnecessary buffering (and hence delays), and the context switch overhead is quite large. Also tight control of the modules becomes difficult.

To avoid these problems, whilst still maintaining good segmentation, the original processes have become lightweight processes within a single UNIX process. The lightweight processes (LWPs) communicate via a specially written lightweight ``pipe" that yield control directly from the writing LWP to the reading LWP as soon as the minimum processable unit of data for the reading LWP is available. The reading LWP yields directly back to the writing LWP as soon as it runs out of data. The H221 stripping and adding modules yield directly to the user interface LWP, which ensures user control information gets processed, and it in turn yields alternately to H221 stripping and adding LWP's. The LWPs also communicate control and diagnostic information using shared variables. There is also an initial LWP that starts everything off. Thus the thread of control is as shown in figure 3.

As you can see from figure 3, the user interface programs are separate processes. A user interface connects to the codec controller over a TCP connection. The codec controller listens on TCP port 7778 (currently hardwired), and a newly connecting user interface process is updated with the current state of the codec controller. Commands from the user interface to the codec controller are blocking - ie if enough commands are sent, it's possible for the interface to block on a write to the codec controller, but this should ensure that commands do eventually get through. Status information from the codec controller to the user interface is written non-blocking, meaning that if the TCP buffer for a connection is full due to TCP backing off on a network with high loss, the status updates will simply be lost, and not cause the codec itself to lose synchronisation. In practise however, this buffer does not usually overflow, but on a very bad network, a user interface may get several minutes worth of updates arrive at once, which can be disconcerting.

In fact the protocol between the user interface and the codec controller consists of simple ASCII commands, and it is possible to control a codec using telnet to port 7778 on the machine with the codec controller, but this is not recommended, and so is not described here .

The software also allows multiple user interfaces to connect to a single codec controller at one time, for both diagnostic and control purposes. There is no interlock between multiple interfaces - any of them can change any parameter. The codec controller does attempt to keep all interfaces up to date, but this may fail if doing this would entail blocking on the TCP connection to that interface. Users are notified of other interfaces joining or leaving.