Orientation

Distributed models based on sharing dependency structures have been explored in EM for some time. A distributed version of the EDEN interpreter ("dtkeden") was developed and deployed by several research students at one time (if you'd like to know more about this, consult the dtkeden manual). Setting up and maintaining distributed models can be a complex process however and latterly there has been little further work in this direction. The introduction of the Cadence environment offers good prospects for changing this situation. This short lab will give you some basic knowledge about how you can deploy Cadence together with a networking module to reproduce the kinds of functionality that were exploited by Nick Pope in programming the video wall (see Chapter 5 of his draft PhD thesis) and have been previously studied in dtkeden.

Exercise: Sharing observables across the network in Cadence

The following exercise is loosely based on Lab 7 from CS405 2006-7, in which dtkeden was introduced. We shall simply focus here on reproducing the kind of sharing of key observables between JUGS models running on separate machines that was illustrated in that lab. To carry out the exercise you will need two machines, preferably adjacent to each in the lab so that you can readily compare their states and responses easily. One machine will act as a server, the other as a client. (It is quite possible to have more than one client.) The process described here enables you to set up Cadence-with-EDEN sessions on these machines in such a way that observables can be shared.

Step 1: On the server machine, start Cadence using

~empublic/bin/cadence

The introduce the following definitions to configure the server for networking: these respectively include the networking module, specify the appropriate port for communication and introduce a client with username and password both set to 'guest':

%include "xnet/xnet.dasm";
 .xnet port = 9040;
 .xnet listen = true;
 .xnet users guest = (new password = "guest")

Step 2: On the client machine, start Cadence using

~empublic/bin/cadence -b "<2:0:0:0>"

The "2" in <2:0:0:0> distinguishes the client machine from the server, which has the object id  <1:0:0:0>. For additional clients use 3,4,... Also include and set up xnet on the client, making sure to change the address field to that of your server machine. You can find your machine's address by typing /sbin/ifconfig into a terminal window.

%include "xnet/xnet.dasm";
.xnet connections 0 = (new union (@prototypes xnet_connection)
address = "127.0.0.1"
port = 9040
username = "guest"
password = "guest"
);

Step 3: Make some shortcuts to the shared object. On the server do:

.jugs = (.xnet users guest);

On the client do:

.jugs = (.xnet connections 0 share);

Step4: Any observables inside jugs will now be shared transparently between the machines. The jugs object is actually the same object located on the server and the client just routes all events for it over the network instead of to a local store. Try the following:

.jugs x = 8;

Exercise: Sharing EDEN observables via Cadence

Using the Oracle and Handle mechanism in Cadence-with-Eden it is possible to use the above mechanism to share EDEN observables of a network. Following on from the above:

Step 5: Introduce EDEN module instances at the server and the client, using:

%include "eden/eden.dasm";

Step 6: Set up an Oracle for EDEN on the server to hold an observable visible to EDEN:

.eden jugsoracles = (new
      type = Oracle
      contentA = 5
)

It is now possible to query the value of the oracle contentA in the EDEN interface at the server via

?jugsoracles::contentA;

Step 7: From the server set up an EDEN handle on the client, and set up a definition to ensure that if this handle is changed at the client, this is reflected at the server:

.jugs jugshandles = (new
     type = Handle
     contentA = 3
)

.eden jugsoracles contentA is {@root jugs jugshandles contentA};

Step 8: At the client, set up handles for the EDEN at the client using object linking:

.eden jugshandles = (.jugs jugshandles);

Step 9: Verify that if you redefine the value of the EDEN handle at the client, using

jugshandles::contentA = 50;

this resets the value of the corresponding oracle observable at the server:

?jugsoracles::contentA;