pots

pots copied to clipboard

This program was originally used at Ericsson's Basic Erlang Course. At the end of day two, you were assigned the task of completing a control program for the subscriber end of the POTS system. There is a graphical simulator, but back then, you could also use the pots program to drive an Ericsson MD101 phone switch and make your own (very local) telephone calls in the lab!

The program contains enough interesting concurrency to illustrate the problem of complexity explosion when using certain approaches. Currently, there is very little documentation. The slides, doc/DeathByQCon100312.pdf give an introduction to the kind of principles that can be explored with this demo.

In the top-level Makefile, there are some ready-made targets for running the system. Simply type make <Target>, where <Target> is one of:

orig for the 'original' subscriber loop version event_fifo for a callback-style implementation, with the ability to block event_fifo_asynch for a variation of the above, where the callback is not allowed to block event_sel where the callback still cannot block, but can control which messages it wants to see next.

If you cannot use GNU make in your environment, the make files should still give you a hint about how to compile and run the code.

Each version "works", for some definition of "works", except the event_fifo_asynch version, which is intentionally buggy. The problem with it is timing-based, and the easiest way to trigger the bugs is to use a special function,

lim:set_delay(Milliseconds). % I usually use 2000, for 2 seconds

You can type this into the Erlang shell. Don't forget to end the command with a period (.) and a newline. What the function does is delay the responses from the Line Interface Module (the switch) by the specified number of milliseconds.

A sequence that is useful for illustrating the timing stability is:

1. Lift the handset of phone A (doesn't matter which one)
2. Put phone A back on-hook
3. Lift the handset of phone A again
4. Dial the number of one of the other phones.

If you do this reasonably quickly, and have the delay enabled, you should be able to see how the animation trails your actions significantly, but actions are still carried out in the right order, and the other phone will eventually ring.

If you do this with event_fifo_asynch, it should get out of synch already in step 2, and you should see error printouts in the shell, as it erroneously discards unknown (but vitally important) messages.