Documentation:Tutorial:RemoteAccess - MdsWiki
Navigation
Personal tools

From MdsWiki

Revision as of 09:45, 22 October 2010; Manduchi (Talk | contribs)
(diff) ←Older revision | Current revision | Newer revision→ (diff)
Jump to: navigation, search

Remote Data Access in MDSplus


In MDSplus remote data access is natively available. Data communication is based on TCP/IP and uses a mdsip protocol. A mdsip server has to be running at the data server side (i.e. where the pulse files are hosted).
The data client then communicates with the data server to retrieve or store data. There are two possible configurations for the data client:

  • Distributed Client
  • Thin Client

In the distributed client configuration most data access operations are carried out at the client site, except for the disk I/O operations which are demanded to the server. In this configuration no changes are required in the code, being data redirection carried out only by re-defining the environment variable <experiment name>_path. More precisely, the variable can contain a search list, separated by semicolons (not colons as for Linux search path). Every element of the search list is composed of three elements in the form:

<mdsip server IP address>:<port>:<directory>

The first element is the IP address of the machine hosting the pulse files and running the mdsip server. The second part is optional and specifies the port number of the mdsip server. The third part is the directory containing the pulse files. More flexibility can be achieved using filemasks, which allow defining directory definitions depending on experiment name and the shot number. In the directory definition you can add special replacement symbols to be replaced by either digits of the shot number or the experiment name. The available replacement symbols are:

  • ~a gets replaced by the one's digit of the shot number
  • ~b gets replaced by the ten's digit
  • ~c gets replaced by the hundred's digit
  • ~d gets replaced by the thousand's digit
  • ...
  • ~j gets replaced by the 10th digit of the shot number
  • ~t gets replaced by the experiment name

For example. assuming that the experiment name is my_tree, directory definition:

/trees/~j~i/~h~g/~f~e/~d~c/~t
would cause the following locations of the trees:

  • shots 1-99 in /trees/00/00/00/00/mytree
  • shots 100-199 in /trees/00/00/00/01/mytree
  • shots 10000-10099 in /trees/00/00/01/00/mytree
  • shot 5987654321 in /trees/59/87/65/43/mytree


As an example,the following definition of cmod_path for experiment cmod:
cmod_path=alcdata::/cmod/trees/test/~t/;alcdata::/cmod/trees/new/~t/
instructs MDSplus to search first machine alcdata: if a mdsip server is running and listening to port 8000 (the default port of mdsip), and the pulse file exists in directory /cmod/trees/test/cmod, then it is accessed, otherwise the second element in the list is accessed, that directory /cmod/trees/new/cmod on the same machine.

In the Thin client configuration, almost all operation are carried out at the data server site. This configuration can be seen as a Remote Expression Evaluation call. The client prepares a TDI expression and then sends it to the server, which actually evaluates it and sends back the evaluation results. Recall that everything in MDSplus is an expression, including the specification of a data item in the pulse file. For write operations, a write expression whose argument is the data to be written is executed by the data server.
Unlike the Distributed Client configuration, the Thin client configuration requires a different Application Programming Interface. Class Connection is the communication broker. Its constructor requires the specification of the IP address of the machine hosting the mdsip server and optionally of its port (separated by a colon). The Connection methods are listed below

  • openTree(tree, shot) which remotely opens the specified tree
  • closeTree(tree, shot) which remotely closes the specified tree
  • closeAllTrees() which closes all open trees
  • setDefault(char *path) which sets the default position in the currently open tree
  • Data get(expression, arguments) which performs remote expression evaluation. The expression is passed as string argument, but may contain optional arguments, which are then passed as an array of Data objects.
  • put(path, expression, arguments) which writes in the specified item (identified by argument path) the passed expression, containing also optional arguments. Arguments are specified in an expression as dollars. For example the following code snippet

C++:

Connection *conn = new Connection("my_server_machine");
Data *args[] = new Data *[2];
args[0] = new Int32(2);
args[1] = new Int32(10);
Data *result = conn->get("(MY_NODE:DATA * $1)*$2", args, 2);

Java:

Connection conn = new Connection("my_server_machine");
Data result = conn.get("(MY_NODE:DATA * $1)*$2", new Data[]{new Int32(2), new Int32(10)});

Python:

>>> conn = Connection('my_server_machine')
>>> result = conn.get("(MY_NODE:DATA * $1)*$2" , Int32(2), Int32(10))

will return the result of the evaluation (on data server my_server_machine, port 8000)of the passed expression, that is the content of data item MY_NODE:DATA added by 2 and multiplied by 10.
The following example will instead write the data specified by my_data Data object in node specified by tag name \MY_NODE:
C++

Connection *conn = new Connection("my_server_machine");
Data *my_data;
... //Fill my_data instance
Data *args[] = new Data[1]
args[0] = my_data;
conn->put("\\MY_NODE", "$", args, 1);

Java

Connection conn = new Connection("my_server_machine");
Data my_data;
... //Fill my_data instance
conn.put("\\MY_NODE, "$", new Data[]{my_data});

Python:

>>> conn = Connection('my_server_machine')
... get my_data Data instance
>>>conn.put("\\MY_NODE", "$", my_data)

Observe the double backslash required to handle tag names in all languages (all them use the C convention).

Using the Distributed Client configuration ha the advantage of not requiring any change in the code, but has a penalty over slow connections. In fact the number of network transactions carried out is much higher than in Thin Client configuration. The reason is that several Disk I/O operations are required per data access, and every one requires a network transaction. On the other side, in Thin client configuration, only one transaction is carried out per remote expression evaluation. As a rule of thumb, Distributed Client configuration is the preferred configuration for data access in the same LAN, while Thin client may provide much faster data access over WAN.
Recall that using the Distributed Client configuration, programs access data exactly as if they were local. Therefore all the classes introduced in the previous section can be used here.