How to use Gestalt

This distribution was unpacked in my public_html directory on your server, and I assume you know how to start a UNIX shell on this server in that directory. It is relavant that your shell be started on the same machine as is running the http server that is serving my public_html directory. Your CLASSPATH environment variable must be set to include my public_html directory. If you are using csh, this can be accomplished in this manner:

codd% setenv CLASSPATH /home/jack/public_html:${CLASSPATH}

The system is started by launching a scheduling server on some machine with the Java Developement Kit version 1.1 or later installed. In most cases, this can be accomplished in a manner similar to:

codd% java gestalt.Server
ClientAcceptor [6501]: I am listening.
SlaveAcceptor [6500]: I am listening.
StatusAcceptor [6502]: I am listening.
Server: Updating the servers we are coupled to...

This will instantiate gestalt.Server, which begins listening on TCP ports 6500, 6501, and 6502. The server takes no arguments from the command line.

Slave machines can then be connected to the server, in either of two different ways. The first, launching the slave application from the command line, is easier and guarranteed to work. However, it requires that you copy or NFS mount my classes to each machine that you would have run the slave application. For simply verifying the functionality of the system, you can run the client, server, and slave on the same machine (but don't expect fast performance). Adding a slave in this way can be accomplished in a manner similar to:

codd% java gestalt.Slave codd
Slave: Attempting to open a socket to the server.
Slave: Creating a new connection.

Adding a slave to a server can also be accomplished by running the slave applet. There are two methods methods I recommend to do this: (1) use the appletviewer program that comes with JDK 1.1 to view the donation page:

codd% appletviewer donate.html
Slave: Attempting to open a socket to the server.
Slave: Creating a new connection.

(2) use Sun's HotJava browser to view the donation page. You can also run appletviewer from a machine other than codd, using the full URL of my donation page. Remember, due to Java applet security restrictions, the slave applet can only open a TCP socket back to the host it was loaded from -- so the machine serving the donation page via http must also be running a Gestalt server. These two methods instantiate gestalt.SlaveApplet, which displays graphics to convey the status of the slave.

All three of these methods eventually instantiate gestalt.Slave, which opens a TCP socket to port 6500 on the server machine. If it is successful, the "new connection" string should show up, and the server will immediately send a series of ten tasks to be calculated. These allow the server to evaluate the speed of the slave.

Gestalt slaves are persistent. By this I mean that if the server to which slaves are connected is killed, the slaves will go into a loop, attempting to open another TCP socket back to the machine specified on the command line until they are killed. Additionally, if a client connects to the server before there are any slaves, the server will still service the client; only no calculations will be performed until a slave is available.

Once there are one or more slaves connected to the server, a client may connect and utilize the server. Here is an example of how to launch flop.FlopMetricClient, which generates a series of flop.FlopMetricTasks, each of which performs serveral floating point additions, downloads them to the server for distribution to the network, waits for the results, and then prints out the network virtual machine's rating in MFlop/s.

codd% java flop.FlopMetricClient codd

Clients take one argument from the command line: the host name of the server it is to connect to. They then try to open a TCP socket to port 6501 of that host.

Finally I will describe the process of coupling servers together, so they may use the slave resources of other servers. The server runs a thread on TCP port 6502 called gestalt.Status, which provides a limited text interface for giving the server instructions, and for accessing data stored in the server. It is particularly useful during the process of testing and debugging the server, but it also serves as the temporary method of informing servers that there are other Gestalt resources available to them.

Let us assume that you have access to two ethernet segments, and that they are connected together by a (comparatively) slow fractional T1 link. You have ten machines on each side of the link, and you want to run Gestalt on your network. You could just run one server, and have all twenty of your machines connect to it, half of which must cross the T1. However, you want to be able to run clients on either side of the T1, and you don't want to suffer the slow down of your client downloading all its tasks to the server across the T1, only to have the server send a portion of them back across the T1 for computation on a slave, back across the T1 for return to the server, and back across the T1 again to return to the client. Instead, you should run a server on each ethernet segment, and couple them together, so that they can use each other's slaves.

In this release, the only way of accomplishing this is by using the status server. One way of getting at it is through telnet:

codd% telnet localhost 6502
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Gestalt 1.0 status ready.
g> 

Typing 'help' will display a listing of the commands that are available, although in depth-descriptions of the information displayed by them is not available. The two commands that are useful for coupling servers together are 'couple ' and 'addServer '. Both commands take one argument: the hostname of the server to attempt to connect to. The difference between them is this: 'couple' requests that the named host be immediately contacted and added as a resource to this server. If the remote server ever goes down, then the connection will be broken, and our server will not try to reestablish it. 'addServer' will add the named host to a list of servers maintained internally. The server periodically goes through this list, and attempts to establish the connections that do not exist. Thus, if you 'couple' a remote server to your server, it will immediately become available for distributing tasks to. If you 'addServer' a remote server to your server, it will become available for distributing tasks to at the next update.

In either case, once a connection attempt has been successful, the remote server will see our server as a client, and will accept and distribute the tasks our server gives it among it's slaves and servers. This 'coupling' is not bi-directional by default; that is, the server to which we couple does not have the priviledge of handing off tasks to our server. This way, it is possible to establish certain pathways for tasks to follow, in accordance with the way the physical network has been layed out.


Last Modified: 7/24/97 by jack@cs.hmc.edu