WELD Client/Server Communication Protocol

Interface Syntax

(Each line is terminated by "\n\r", including one additional line after the last line given). 

Called when a tool informs of the registry/data server of its availability.

• Resource Register

(Resource) Client:

REG 
<DB Identifier String>
<ResourceName>
<ResourceMachineName>
<ResourcePortNumber>
<Number of Input Args for the tool> (in format #, or #-#, ie 1, 1-4)
<Number of Outputs> (in format #, or #-#, ie 1, 1-4)
<Possible input types> (string description)
<Possible output types> (string description)

Server:

<XXX> (Three digit status code)

• Resource De-Register

(Resource) Client:

DEREG 
<DB Identifier String> (Is this necessary/reasonable???)
<ResourceName>
<ResourceMachineName>
<ResourcePortNumber>

Server:

<XXX> (Three digit status code)

Assumption: Tools will not stay down for an extended period of time without de-registering.

Tools can re-register, after a crash.

The triplet (name, server, port) which "should" be unique.

• Query Registry

Client:

QUERYREG 
<DB Identifier String> 

Server:

<XXX> (Three digit status code) 
<NumContents> 
<ResourceName> (the triplet of each available server will be listed)
<ResourceServerName>
<ResourcePortNumber>
...

(*Rationale: The tool/service name, server and port are the only essential information needed for a client to make a connection.) 

The data server needs to know where (which table) to look for the information.

• Resource Lookup

Client:

RESLOOKUP 
<DB Identifier String>
<ResourceName>
<ResourceMachineName>
<ResourcePortNumber>

Server:

<XXX> (Three digit status code)

<TimesRun>
<TimesFailed>
<AvgRunTime> (seconds)
<TimeSinceStarted> (seconds)
<Last 10 results> (string of 10 chars : F/S/N (failed/success/not run yet)
<Number of input args>
<Number of outputs>
<List of workflow names> (strings, separated by characters)
<Input description field>
<Output description field>

The triplet (name, server, port) which "should" be unique.

• Resource UPDATE

Client:

RESUPDATE 
<DB Identifier String>
<ResourceName>
<ResourceMachineName>
<ResourcePortNumber>
<Workflow name>
<LastRun> (S for success, F for fail)
<LastRunTime> (integer #seconds)

Server:

<XXX> (Three digit status code)

Execute:

Client:

EXECUTE 
<DB Identifier String> 
<ToolName> 
<ParameterString> 
<Time interval of Heartbeats>  (in seconds, N for NO heartbeats)
<Number of Data Inputs> 
<Data>  (one for each number above, none if number is 0)

Server:

<XXX> (Three digit status code) 
<Data> 

The three digit status code should be "OK" to indicate that the tool has started running. Data is only meaningful if the status code is an error, at which point the tool has stopped. If there is no error, after it has started running, if heartbeats are on, it will return messages at heartbeat intervals, consisting of either :

<XXX> (Three digit status code) 

(where the status code is "OK" (alive, but not done)) or

<XXX> (Three digit status code) 
<Number of Data Outputs> 
<Size of Data Output>  (number of bytes, N if not available)
<Data> 

(where the status code is "FAIL" or "DONE") (The last two fields are repeated for the number of data outputs. Data of some sort must always be returned, even if (especially if!) the tool failed)

This should be enough for our needs, we will continue to study the syntax of (different) RPC(s).) 

The first-cut implementation will be to have the clients send and receive the data that is to be transmitted. However, we will investigate different mechanisms where the data field can be replaced by a "pointer" to the data location, such as DataObject in the database, URL, etc. (for efficient data transfer).