Distributed Pipe
Name: Distributed Pipe
User Interface: The user interface is console based. The command formats for the
distributed pipe are as below.
dp: The command dp is used to chain distributed programs.
Usage: dp HostId -uUserName -pPassWord ProgramId [HostId1 -uUserName pPassword ProgramId1] -fFileName
Eg:
dp H1 -uckn -pkill P1 | H2 P2 | H3 P3 23:45 [-fScientific.dat]
Here the time “23:45” in the last part of the command tells that the program P3 should be
started at 23:45 local time. The output is finally received and is displayed to the screen,
unless it is redirected to a file. User names and passwords are not necessary for some
public servers. The “-f” option is to accept a file for data input to the first host. Once the
above command is executed at the shell, the console is divided into two windows using
curses library. In one window the user can give one of the two commands “status” or
“cancel” and in the other window the status gets displayed.
dpgetproglist: This command lists the programs that are available for execution at a
particular server.
Usage: dpgetproglist HostId [-uUserName -pPassword]
dpman: This command brings up the manual page of a particular program from the
remote server.
Usage: dpman HostId [-uUserName -pPassword]
The Protocol
The protocol gives the following commands to the applications written on it.
Authenticate
Send
Store
Execute
GetProgramList
Get ManPage
Abandon
Get Status
Close
Authenticate: This command goes from a client to a server and it carries the user name,
hostId and a text-based password. The server authenticates the parameters and it sends an
ACK or NACK. With the receipt of an ACK, a session is said to be established between
the client and the server.
Send: This is to start a transfer the output of a program execution from one server to
another server. The client executes this command when it gets an acknowledgement from
the server saying that it has finished the program execution and the output is ready. The
client then sends the “send” command asking the server to send the output to a different
server or the client. The server sends a response to the client when it receives the “Send”
command. The server also sends another response after it actually sends the data to the
next server and the next server acknowledges it.
Store: The store command is a request asking the other side to accept and save the data
that is being sent as part of the “store” command. A client can use “store” to send the data
initially to a server. A server uses the “store” command to send data across to a different
server. A server sends data across to a different server only when the client requests the
server to do so by issuing a “send” command. The response to the “store” command is
from the server, which accepted the data to the server, which sent the data. On receipt of
the data an acknowledgement is sent back to the server.
Execute: The command execute is always issued by the client. This is issued after the
data is sent to the server with the “store” command. It is possible to delay the execution
of the program on the server side by specifying the delay as an option in the “execute”
command. A response is sent to the client after the execution of the program indicating
the status of the execution.
Abandon: Each command has an identification number. This command is issued to
cancel a command with a particular identification number. If the command is already
executed on the other side, then the abandon command is ignored.
GetProgramList: The client issues this command to the servers to know its capabilities. In
other words, to know the programs that can be run on the server. The sever returns a list
of the program names and other identification information in the response.
GetManPage: The client issues this command to know the usage and functionality of a
particular program that is supported by the server. The server returns the Unix-style manpage for the command in the response.
GetStatus: The client issues this command to know the status of the program that is being
executed on the server. The server returns the time elapsed since the program started in
milliseconds and also returns status of the program viz. RUNNING, ABORTED etc.
Close: The close command is used to close the session between the client and the server.
Client-Server Interaction
The Client initially sends an “authenticate” command to all the servers specified in the
distributed pipe. If any one of the authentications fails the client specifies which one
failed and terminates. After the authentication process is complete for all the servers, the
client establishes a session with the first server by again using the “authenticate”
command. The client then sends the initial data files if any to the first server by using the
“store” command. The client responds to the server by acknowledging the receipt of the
files. The client then sends an “execute”, which specifies the program to be executed on
the data that was sent. When the program execution is complete, the server responds to
the client with the result of the execution. Typically the results of an execution are
“Incorrect Parameters”, “Program aborted” and “Success”. Once the client receives a
response, it observes if it is a success or not, if success it sends a ``send'' command to the
server asking it to send the data to the next server. The server sends the data to the next
server using the store command. This process continues till the last server and for the
server, the client asks to write the output back to the client.
For the output data transfer from server to server on demand by the client, we would like
to generate a random numbers when the client initially authenticates itself to the servers.
And the client would then pass that number to a server and would ask that server to
establish a session with the next server using the number it gave and then transfer the
output of the program execution on it’s side.
We know that the protocol won’t work the way we specified in this document unless we
change some of the ideas described. This document is just putting our basic and initial
ideas on paper and would thus form a basis for a more detailed and relatively robust
description we will submit next week. We didn’t talk about the implementation details, as
we haven’t still fixed the technology we will be using. We want to do some basic
groundwork before we choose the right one, as we are new to all those possible
approaches you gave. The straight socket implementation is familiar, but we would like
to see if there’s any other technology, which would give us more mileage in the short
time, we have ahead.