On Apr 15, 2005, at 12:43 AM, Ken Ray wrote:
I'm trying to get two apps to talk to each other over sockets on OS X, which
means that both apps need to be in "listening" mode as well as "speaking"
mode.
There are two approaches you might take. One is to announce an "error" when you cannot connect. The other is a "tenacious" approach that I often use. In this, there are no fatal errors, only "not ready" states. This is also handy in replacing a live application with another.
The "tenacious" approach has a top level "open" that simply states the need for a connection underneath. That can be closed. The machinery underneath keeps trying to open until it is open (think send-in-time). If the connection is closed by the other end, it go back to the open trying mode. You might try this every few seconds. The channel would have a state that is "not ready" or whatever at times. You might have a light on the panel that indicates this.
(If you try this with UDP on Windows, you will need to make sure your delays between tries are not too short or you will get errors from previous tries.)
Do the same with the listening. It can be tenacious, too. What if the net is down or an earlier version has that port?
Here is the key. With tenacity, once the state of the system is right, no matter what order things happened to get there, things work.
I use this in distributed unattended systems that must keep going. My apps can't quit just because of some hiccup. And they can't stop working and display some dialog box and assume an operator will fix things or call me.
Stack 2 (listens on 60000, sends on 59999): Listen Stack 1 (listens on 59999, sends on 60000): Listen Stack 2 (listens on 60000, sends on 59999): Connect Stack 1 (listens on 59999, sends on 60000): Connect OpenSockets: 60000 59999 127.0.0.1:59999 127.0.0.1:50321 127.0.0.1:60000 127.0.0.1:50322
I also don't understand where these other sockets are coming from...
You don't really chose what socket you are opening from in Revolution sockets. If you open a socket to port 12345 on the remote (which could be local), the TCP system will assign a port for your end.
There is nothing wrong with your crisscross (scissors) link. It is a great way to allow symmetrical communication among peers. However, sometimes (often because of firewalls), there must be a directed TCP connection. I think you can generalize the tenacity approach to that. Or, make that directed connection a VPN link or a SSH tunnel outside your app.
If the computers do a server-client relationship, I don't think you would normally want the two connections.
Remember that all stuff for one end should be in the same script, that is, in the script for one object. That would apply to each half of your end, but it might be easier to combine them.
Use little red/green indicators. They make you smile when things work. Well, they make me smile, but I am easily pleased.
Dar
--
**********************************************
DSC (Dar Scott Consulting & Dar's Lab)
http://www.swcp.com/dsc/
A Sponsor of RevCon West
**********************************************_______________________________________________ use-revolution mailing list [email protected] http://lists.runrev.com/mailman/listinfo/use-revolution
