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
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