Socket Comm Sequence Issue

[Dar Scott]

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
**********************************************