This is in line with a question asked but not answered on the other list.

Is there a way/how do you communicate with another computer using IP/PORT. I would think that there must be something in the ftp or other socket tools that would allow this.

ideas

First you have to decide whether you want to be a client or a server.

Second you have to decide what protocol.

The rest is pretty easy. If you beat your head on the desk long enough.

What are you talking to?

Steve

steve@state-of-the-art.com.au

hmm .. how about communicating between OI clients.

Um - locks? files?

If two clients connect then one has to be a server. Which means two clients can't connect. Because one wouldn't be a client.

Another option would be to use OICGI or OECGI (which listens) then parse the responses.

But if you want to do server side sockets…

What are you trying to achieve. You never said what the problem was.

a problem .. no .. but an opprotunity .. yes

Just thinking of a way to have some messaging internal to OI. cant use oecgi as as there is no web server involved. More of a client x did this which fires a message to client y to be notified that something has to happen.

I could create a message file or some such .. but looking at a way for each client to have minimal communication between boxes.

just something i have always wondered about. If you can read/write a port/ip then i should be able to have a little routine, run off the timer. check the port and do accordingly .. yes?

No. How would you know when to poll?

You'd be better off pasting data to the clipboard if the sessions are on one machine.

If you're on multiple machines, write to a commonly attached file.

Think of it like the server is the catcher in baseball and the client is the pitcher and the message is the ball. The server/catcher has to be constantly waiting for the incoming ball. It can't merely wake up every so often and catch balls when it likes, and sign autographs the rest of the time. You get the picture. A server is 100 percent attentive to incoming messages.

so that is what a server is .. wow

as mentioned in the last posting .. i could write to a file .. but was look for something a little more fun

guess it isn't in the cards

thanks .. i'll try that catcher thing

DSig,

We developed a proof of concept of this using remote engines. I posted this before somewhere. Basically, a dedicated engine was running on a server. The OI clients would post messages, which were stored in a common variable. OI clients would also query the common variable for any messages that were meant to be received. Thus, we had a type of instant messaging system for OI. However, as Steve has elsewhere commented, the system can't be "signing autographs" and know when to come back into the game. It has to always be in the game. To accomplish this, we would have a dedicated window (i.e. the "chat" window) running a TIMER event and making remote engine calls at a pre-determined rate.

At the time our goal was to see how well we could write a pure OI instant messaging utility. As a proof of concept it worked. As a practical utility it left a lot to be desired. When more than 2 or 3 clients connected there was a noticeable lag. However, we set the TIMER event interval to be very small. I imagine that if you wanted a basic messaging utility so that processes would be triggered then you probably a.) don't need multiple clients and/or b.) don't need such a small interval. Therefore this solution might work. The advantage of a common variable, of course, is no disk I/O. The disadvantage is that if the system shuts down then you might not have any record of unprocessed messages.

We had high hopes for a socket based solution to this. We had even contacted Steve for his thoughts and possible help. He explained the challenges of doing this with the current socket implementation with OI…which caused us to consider other options. We now have something in progress that should provide the foundation for very responsive and flexible messaging for OI apps. We are currently using it to maintain synchronous schedules and calendars for businesses that require real-time display of dispatched work trucks. Our goal is to deploy the core of this tool into a generic OI-to-OI communications utility.

dbakke@srpcs.com

SRP Computer Solutions, Inc.

although i still find the bb image a stretch ..

we had penciled out an "engine msg server" and had planned on using the timer functions. but as it appears cant be done in OI we will look for a solution out of OI.

thanks

I have recently discovered it is possible to spawn an additional thread inside OI from a DLL which can then listen to a socket while OI carries on its other processing. The DLL can buffer incoming messages and then deliver these on demand to a calling Basic+ program (which acts as a message collector).

I've had to work on an assembly language interface for OI as a precursor.

And there are still a few impediments to this approach which I'm working on.

But I haven't given up just yet. Just my brain is a little slow at assembly under Win32.

DSig - any chance of you setting me up another FTP account on a FTP server for non PASV FTP testing?

Steve

1. The OeSocketServer.jar exists to let outside agents communicate with Engines via socket connections. CTO and OECGI2 are 2 clients, but it is designed to handle any client. You could use it to have one engine talk to another. The protocol is based on the JD3 project.

2. You can use OECGI without a webserver. You just need to

 a. set the registry up appropriately  ( EXEC OECGI_CONFIGURATION ) then

 b. Set 2 parameters in the dos Environment

 SET QUERY_STRING=myparam1=a&myparam2=b

 SET PATH_INFO=/INET_MYPROGRAM

 c. Runwin or ShellExecute OECGI

HTH

Bob

sure .. email me so i can send you a login/password

View this thread on the forum...