Yang Zhao (ellen_zh@eecs), Thomas H. Feng (tfeng@eecs)
Contents
Abstract
The concern of this project is to develop the prototype of a framework, which enables distributed modeling and execution within Ptolemy II. It consists of two main parts:
Distributed execution. With the support of this framework, a model can be designed in such a way that it runs on conceptually multiple machines. Ptolemy II and this framework can actually execute it with its correct semantics.
Distributed modeling. Designers from different parts of the world contribute to the design of a single model at the same time. They may also observe a single execution of the model, and send it control commands.
Specifically, in this class project, we try to solve the essencial problems in distributed execution. A design for distributed modeling is similar.
We propose one possible design of such a framework, which requires very limited changes to Ptolemy itself. A lookup service and a gateway are involved in our design, and they function together to render powerful functionality to Ptolemy users, such as dynamic lookup, life-time and security.
The overall deployment is shown in Figure 1, “One possible deployment with two PC's, one PDA, and the lookup service”. To run a model distributedly, each of the involved machines (PC's, Apple machines, Java-enabled PDA's, and so on) must have an instance of Ptolemy running on it. [1] Those machines use a global lookup service to locate each other. This service, which they by default connect to, acts as the DNS in the Internet, with much more functionality (we will talk about this later).
To effectively communicate with each other, they also need a gateway running on each of them. The gateway is discussed next.
Each Ptolemy instance, if it allows to be used distributedly, must have each of its connections cordinated by a gateway. The gateway simplifies the task of the Ptolemy instance, and it also provides a rich API to it. In this project, we will explore either or both of these possible designs of the gateway:
The gateway is on the same (conceptual) machine with the running instance of Ptolemy. It cordinates all the connections and filters the incoming and outgoing messages. We will discuss its functionality later.
The gateway is remote from the machine. This scheme slows down the execution because Ptolemy has to interact with the gateway with an extra connection. However, it is more feasible for the design of PDA's, which has very limited computing resources.
There are many benefits by using gateways, and here are some among them:
Minimum change in the Ptolemy class hierarchy. The gateway can be developed as a completely separated process, communicating with Ptolemy with a well-defined protocol. Candidate protocols for this communication include RMI, CORBA, sockets [2], and even disk files.
Flexibility. As many communication protocols as possible should be implemented on the gateways. Though at the same time a pair of gateways communicate with only one of the implemented protocols, the choice is dynamic or left to the designer who determines the deployment configuration for a given model.
Ease to debug and analysis. Testers may trace the activity of the gateway to find bugs, determine bottlenecks, detect unauthorized connections, and so on. This is much easier than looking at individual actors, which may (or may not) create direct connections to send or receive messages without being cordinated.
Security. Actors within Ptolemy are not allowed to establish connections without doing this via a gateway, which finally has the right to filter all sorts of dangerous connections and messages. This provides a base for executing an unauthorized script or Java class locally. (Of course, many other security mechanism should be added on top of this level.)
Many crucial services can be implemented on the gateways, including life-time and security. These concepts will be clarify in the final project.
On the one hand, one would like the gateway to provide a rich API to Ptolemy; on the otherhand, the design of the gateway must be concise so that even a user with 256M memory or less is willing to run it as an extra process in the background.
The lookup service, as it functions like the global DNS, resides at a relatively static location, which is understood by each Ptolemy instance before it starts up. This, of course, can be configured using an XML script.
When a Ptolemy instance starts up, it registers itself to the lookup service (via its gateway). The lookup service, possibly, stores its name, type and behavioral keywords for the lookup requests from other Ptolemy instances.
A gateway, when the Ptolemy instance associated with it requests to lookup other instance(s) according to a specific criteria, relays the lookup request to the lookup service. A set of address(es) to other machines are returned as a response. The gateway keeps the set of addresses in an internal location table, and returns the corresponding index to the Ptolemy instance as a handle.
When the address set contains only 1 element, the connection between this Ptolemy instance and the other one is equivalent to a 1 to 1 connection. A message sent from one instance with the correct handle is uniquely received by the one on the other side.
When the address set contains more than 1 element, a 1 to many connection is established transparently (i.e., without notifying the Ptolemy instance). When a message is sent with a 1-to-many handle, the gateway automatically broadcasts it according to the addresses in the location table. Each of the targets will receive a copy of the same message.
Each gateway must periodically report the current status of its Ptolemy instance(s) [3] to the lookup service. When one of the Ptolemy instances within the model malfunctions (deadlock, hacked, disconnected unexpectedly, hardware error, ...), it is effectively removed from the lookup service, and well-isolated from then on.
In a word, we are trying to facilitate distributed model execution in this class project. Our work will consist of two main parts: a gateway and a lookup service. Limited changes to the Ptolemy class hierarchy are also required.
[1] To ease the design of PDA, a very simplified and code-generated Ptolemy may be used on it in practice.
[2] If the gateway and Ptolemy are on the same machine, we need not worry about such problems of sockets as big-endians and small-endians, package size, ...
[3] May be many, though found in very rare cases.