Neil Nelson wrote:

> 5:24 am here.  I bug holding the ICSA up a whlie was that on a client type

> connect command where all socket commands are nonblocking, connect

> will always return an error indicating that it has not connected because the

> connect process is still being performed when the command returns.  Either

> the ICSA needs to wait or it needs to check later that the connect has

> completed.



Since ICSA is going to run in paralell to it's app users, it can do

anything it wants in the time being. The Console will be happy to wait

any additional time ICSA takes to execute a procedure, since it never

expected an instant response from a remote computer and requesting

responses is all it ever does.



Since orders for the ICSA will be appended to the interface file and I

guess the ICSA will be picking the entries off the top and since ICSA

has to do with indentity verficiation, I suggest to pick the "waiting

for a response" option, the rest of the system is flexible enough to

tolerate you-pick-a-lenght delays.



> In addition ot cleaning up and modularizing the code, I am working on a

> good quality time sync routine between the user PC and my server on NTP

> time.  I expect I need to deliver an initial review version soon, but

> want to cover the basic features up to the encryption routines: we want to be able

> to send and receive messages and files between arbitrary IPs and local

> communication files, and sync the time.  I am also thinking about a named

> pipes communication.  (I just looked through Microsoft's developer reference

> site and named pipes appear to be available for C but not for VB.)



Pipes can be achieved in VB by inserting a "command.com /c" in front of

the line, this does mean that a DOS command interpreter is required but

I sincerely doubt there is a Windows platform without one.



> I worked with the Society application briefly but did not get it to do

> anything. It must be in development.



Unless I sent you the new version of the Console and you have an ICI

environment variable set (which I doubt), it should work with the

Console on with it's "Input ICI commands from PO file" checkbox checked.

Note that you have to have about version 263 or something, because I

just recently added the "SPREAD" command to the Console's vocabulary (it

means: "unconditionaly send to everybody in cluster including myself"),

which is used by the app. It could be that it is only included in the

latest version, which dosen't exaclty work and/or that I forgot to send

you something.



I'll fix the latest version and send it over.



> For the `Results' function, an application calls the ICI to call a

> function.  The ICI can either call the function and then return the reply--a `Results'

> function-- or it can send the calling function a file location where it can get the

> reply and send the called function the same file location where it can send

> the reply and then be out of the loop.  E.g., it might occur that an application

> would want to have a sampled speech file, as would be obtained in the Speech

> communication method, sent to a voice or word recognizer located on the ICI network.  That

> calling application would send a request to the ICI to word-recognize

> the file at filename.  The ICI would either have in a table the IP where such a

> process could be done--likely in the case where such frequent request was made

> locally, or may, for the initial request, perform a `where-is' against ICI system

> indexes containing resource lists.  The ICI would then be able to route the

> request to the proper IP and process with a return IP and process filename.



The trick is that I have to keep the Console as universal as possible.

As you probably know it is very hard to *hardcode* something *flexible*.

=]



The file idea is very good because ICSA is expected to be able to

transfer files and with a computer name and a pathname a program could

bypass the Console with it's request for information, which means one

less part in the chain and is rather perfect.



Otherwise a "Results" function would be just so like the design of ICI!!

=] You probably remeber that we had a bunch of rather unsolvable

problems when we began working on this and we said that user would

simply take over where there are missing components, so if we needed a

service or component, we would simply name it and the problem would be

solved. So true! Now when we have a problem, we simply name a function:

"Results" and the problem *is* solved. =] Hard to belive, but true.



> But we are waiting on my code.



Take your time. You get a fair chance of a good solution simply poping

to mind if you do. =]



--



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

