PDF (double-sided) - Physics Department, UCSB - University of ...

waiting for their completion. The Client then needs to be able to sort through
the Replies to re-associate them with their corresponding Requests. This is done
by tagging every outgoing Request with a unique, positive Request ID. When a
Server handles the Request, it tags the Reply with the negative of the Request
ID (Request 5 yields Reply -5). It should always be possible for the API to take
care of the entire management of these Request IDs.
Therefore, if an API is
written well, the Module developer should not ever have to come in contact with
Request IDs. For the development of Server Modules, the API can even hide the
entire Packet structure of incoming Requests by always passing the Requests to
the Server on a Record by Record basis. This way, the Server developer does not
need to be concerned at all about whether, for example, two Request arrived as
two Packets with one Record each or as one Packet with two Records. By being
in sole charge of the construction of the Reply Packet, the API can then enforce
the correct Packet structure to ensure compliance with the LabRAD protocol.
The LabRAD APIs should also assist Server development as much as possible
with the management of Contexts. Contexts are intended to provide a method
for Server Modules to maintain data that persists across Requests. For example,
a Client might select a device it would like to use. To reduce redundant traffic,
the Server should be able to remember this selection as well as any relevant device
settings for future Requests. For this, Contexts provide an index into a memory
148