ERLINK-SR Switcher

The switcher allows messages to be switched between clients. The easiest way of explaining is to run a session.

Install Erlang for Windows (http://www.erlang.org/download.html) or Linux (use Synaptic on Ubuntu).
Download and unzip the software anywhere you like.
In a command window change to the directory containing the .beam files which are the compiled Erlang files.
Follow the session below. The bold type is prompts, italic is what you type in and normal is the system responses and information output.

Transcript	Comments
D:\srs\core\erlang\erlink-sw\ebin>erl -sname switcher -setcookie sdrnet Eshell V5.5.1 (abort with ^G) (switcher@LT-VAIO-100)1> sysmon:system_startup(). true	From the command prompt start Erlang telling it it's node name is switcher and it's cookie is sdrnet. Cookies are a primitive security mechanism and all communicating nodes must use the same cookie. As we are running one node here it's not necessary but it is what I use in the full system.
(switcher@LT-VAIO-100)2> tester:test(class1, tester1). Tester <0.36.0>: Starting new tester process for class1 Tester <0.40.0>: Waiting for registration response message for class class1 <0.40.0>Tester <0.40.0>: Received my gateway <0.41.0>	Tester 1 We start three tester processes. As each starts they register with a special registration process the switcher creates. The register then in turn creates a gateway process which is private to each connected client. The identifier (known as a Pid) is returned to the caller which it must use in all future communication with the system. The two parameters passed are the class of this client and the name by which this tester can be referred to when sending it messages from the command line. Confusingly this is also a registered name but in this case registered with Erlang and nothing to do with the switcher. Messages can only be sent to a class, so if two testers register with the same class name they will both receive messages sent to that class. In this way messages can be sent to a unique destination or broadcast to a sub-set of the clients. A good example is having several displays which all require display updates or having a main UI with a frequency display but also a separate node which is just a frequency controller and both need updates to the frequency etc.
(switcher@LT-VAIO-100)3> tester:test(class1, tester2). Tester <0.36.0>: Starting new tester process for class1 Tester <0.43.0>: Waiting for registration response message for class class1 <0.43.0>Tester <0.43.0>: Received my gateway <0.44.0>	Tester 2
(switcher@LT-VAIO-100)4> tester:test(class2, tester3). Tester <0.36.0>: Starting new tester process for class2 Tester <0.46.0>: Waiting for registration response message for class class2 <0.46.0>Tester <0.46.0>: Received my gateway <0.47.0>	Tester 3
(switcher@LT-VAIO-100)5> tester3 ! {outbound, class1, 'message to tester1&2 of class1'}. Tester <0.46.0>: Tester outbound msg is 'message to tester1&2 of class1' {outbound,class1,'message to tester1&2 of class1'}	Send a message to tester3 destined for class1.
(switcher@LT-VAIO-100)6> tester1 ! {poll}. Tester <0.40.0>: Tester polling <0.41.0> {poll}Tester <0.40.0>: Response to poll 'message to tester1&2 of class1'	Received the message at tester1
(switcher@LT-VAIO-100)7> tester2 ! {poll}. Tester <0.43.0>: Tester polling <0.44.0> {poll}Tester <0.43.0>: Response to poll 'message to tester1&2 of class1'	and at tester2.
(switcher@LT-VAIO-100)8> tester2 ! {poll}. Tester <0.43.0>: Tester polling <0.44.0> {poll}Tester <0.43.0>: Null response to poll	Just to show the queue is empty now.

To be honest there is a limited amount you can do with this apart from maybe automate the test harness a bit to fire lots of messages around or do multiple registrations, more testers, remote the tester nodes etc . It does at least prove the Erlang side of things and adding the real clients when I make them available means there is less to do in one go.