Neil Nelson wrote:

> The following describes the current format of the communications

> file for applciation to application commands.

> 

> The primary file communication format is currently designed to

> transfer commands to ICI Console programs. A file named `icsa.cmm'

> is placed in the communications directory and then the ICSA reads

> that file, deletes, and executes the commands obtained from that

> file such as:

> 

> source_process ici

> source_ip 192.168.0.3

> destination_process ici

> destination_ip 192.168.0.2

> remote_command "this is a remote command 2"

> 

> - source_process identifies the program providing or sending the

> command.  This is required.

> 

> - destination_process is the name of the program receiving the

> command on the remote computer.  This is required.

> 

> from which a lookup of the IP for Harold will take place.  That

> table entry will have previously required a request to the server

> to get the dynamic IP.  Or perhaps that lookup can be made when

> a name is used and the table entry is not yet present.  A problem

> occurs when the computer for that dynamic IP is not connected to

> the Internet which then requires a reply for that condition to the

> local application (ICI) that we may want to discuss.



If ICSA cannot execute the command in it's interface file now, it should

leave it there. As I mentioned in my previous post, if my Command

Transfer protocol is used, the overwriting problem disapears. In this

case, the next time the ICSA will check the top entry in it's interface

file, it will too check for an internet connection. If this connection

is present, the command will be sent then.



There of course is a little problem: This would work cool, but would

have a big problem if the reason for the falioure is in the interface

file entry itself. The Console avoids this problem by ignoring commands

it cannot execute, but this is no solution. 



As I think of it now, perhaps if any problematic entry would be moved to

the bottom of the interface file, this would solve the problem:

Unexecutable commands would simply loop in the interface file, allowing

the other commands to get executed. This solution isn't perfect either

(the command send order is automaticaly ruined), but it's better than

anything we have so far.



There is also the point that in ICI's command distribution system, a lot

of commands (all those that can't be executed on all the computers they

were sent to) are EXPECTED to be IGNORED. So I don't know how this

combination will run out.



> Currently the output file of the command, the file on the remote

> computer made available to the remote ICI, would contain only

> the remote command portion, e.g., from above:

> 

> --- start example ---

> this is a remote command 2

> --- end example ----

> 

> or only the character string after the double quote when `follows'

> is used.  I will change the code so that the word `follows' can be

> avoided, only `remote_command' will be required so that the

> double quote area will be assumed.



Ah, yes this solves a problem for me, thanx. It dosen't sound right,

because I will have to merge the Command Flow protocol with the Data

Storage protocol sooner or later anyway, but no reason to make things

complicated, where they can be simple.



> - get_ici_time is an additional minor command that will return

> the number of seconds and milliseconds (9999999999:999, plus

> or minus around 100ms) since the beginning of 1970 in ICI time

> once the time sync has been made.  A routine to format that to

> either a more familiar time at longitude zero or at the likely

> local time will be written later.

> 

> I will send the file transfer format next.



Ok. C'ya!



--



Don't feel bad about asking/telling me anything, I will always gladly

reply.



Digging for info? Try AI Meta Search:

Http://WWW.AIMetaSearch.Com



MesonAI -- If nobody else wants to do it, why shouldn't we?(TM)

Http://WWW.MesonAI.Com

