Multi-Process TCP/IP connections

[ConvertFromOldNGs]

by Roland Pope >> Sun, 4 Feb 2001 22:37:00 GMT

I have a want to create an application that will fire off a separate process for each TCP/IP connection it receives on a selected port.
If I use ListenContinuous, I always have a port available for connect, but cannot use another app to process the connection as the connection object is transient.
If I do a listen, and when I get a connect, spawn off another app to take over the listening, won't there be a window of time where there is nothing listening on the port? Also, what happens if I get two simultaneous connects??
Any Ideas??

Thanks
Roland Pope
JADEDirect

[ConvertFromOldNGs]

by Krull >> Mon, 5 Feb 2001 0:46:02 GMT

Hi Roland,

One way to achieve this is to keep using a single listen process, fire up a new process and establish a reverse port.

Consider the case were system A wishes to connect to system B, the steps are as follows:
System A performs the follow steps:
a) offer a listen on a nominated reverse port (passive open)
b) perform a normal active open to system B
c) [send handshake message] optional

System B performs the following:
d) system B is notified of a new connection via its listenContinuousAsynch callback
e) [receive handshake message] optional
f) listenContinuousAsynch callback fires off a new process and closes the primary 'listen connection'.
g) new process opens a connection to the reverse port offered by system A in step a)

steps c) and e) are optional but can be used to exchange the port number for the reverse connection. If system a) is always 'a client' you could use the same port number as that used for the listen. Beware of firewall/proxy issues with opening reverse ports.

You might like to consider submitting a NFS requesting support for this capability from JADE's TcpIpConnection class to make this easier while also avoiding firewall/proxy issues.

[ConvertFromOldNGs]

by Roland Pope >> Mon, 5 Feb 2001 1:38:31 GMT

One way to achieve this is to keep using a single listen process, fire up a new process and establish a reverse port.

This idea is fine if you have the luxury of controling both ends, or if you are establising your own protocol. In a situation where you have to use a specific protocol (SMTP for example), there isn't this option. Most mail servers will expect to connect to other MTAs on port 25 with no option for using a reverse port, and many other protocols are similar with no "Port Callback" type facility.

[ConvertFromOldNGs]

by Krull >> Mon, 5 Feb 2001 2:48:42 GMT

One way to achieve this is to keep using a single listen process, fire up a new process and establish a reverse port.

This idea is fine if you have the luxury of controling both ends, or if you are establising your own protocol.

Sorry, I did assume that was the case since you didn't mention a specific protocol in your requirement.

In a situation where you have to use a specific protocol (SMTP for example), there isn't this option. Most mail servers will expect to connect to other MTAs on port 25 with no option for using a reverse port, and many other protocols are similar with no "Port Callback" type facility.

Yes, if you need to support a specific protocol such as SMTP then you can't use a reverse port. Are you constructing some form of MTA in JADE?

Have you considered something a long the lines of the following: using a single communication or router process, which accepts connections, receives/sends messages and then passes them to 'worker processes' via an internal message queue?

[ConvertFromOldNGs]

by Roland Pope >> Mon, 5 Feb 2001 4:01:30 GMT

Sorry, I did assume that was the case since you didn't mention a specific protocol in your requirement.

That's OK, I should have been more specific.

Are you constructing some form of MTA in JADE?

Yes, although it will just be a basic SMTP destination and won't have to get into the complexities of relaying etc...

Have you considered something a long the lines of the following: using a single communication or router process, which accepts connections, receives/sends messages and then passes them to 'worker processes' via an internal message queue?

Yes, although I was hoping to avoid the potential complexities and overhead of needing to code my own Server->Worker Heirachy.
But that seems like the best option since I have been thwarted in my original attempts to do something along the lines of 'connectionObject.listenContinuousThenStartAppMethodWithConnectionObject("My Schema","MyApp",ConnectionObject) '
Mmmmm, is that an NFS I can smell brewing ............

Roland Pope
JADEDirect

[ConvertFromOldNGs]

by Krull >> Mon, 5 Feb 2001 4:47:11 GMT

But that seems like the best option since I have been thwarted in my original attempts to do something along the lines of 'connectionObject.listenContinuousThenStartAppMethodWithConnectionObject("My Schema","MyApp",ConnectionObject) '
Mmmmm, is that an NFS I can smell brewing ............

Yep, it would be worthwhile submitting an NFS even if you have to implement it a different way in the meantime.

[ConvertFromOldNGs]

by Eric Peachey >> Mon, 5 Feb 2001 20:03:26 GMT

Yep, it would be worthwhile submitting an NFS even if you have to implement it a different way in the meantime.

Perhaps when Roland submits his NFS he could ask for the documentation on TcpipConnection class to be improved. The documentation, particularly with regard to how Jade handles multiple connection objects (created as after listenContinuous). It's not clear how any multithreading (if any is done) when you have multiple connection objects belonging to the same process - what happens when one connection object is processing and a message arrives for another connection object? Does the second one have to wait for the first one to complete? The help on windows events doesn't touch on this topic. It would be helpful to know more about this kind of thing. I know of one solution that has multiple applications (processes) each listening to separate ports (requiring a plethora of ports), and another which does a listenContinuous which results in multiple connections belonging to the same process (with the connection objects holding their own state and going in and out of transaction state when handling certain messages). Both of these solutions seem to work (i.e. in production without apparent problems). The former was built this way apparently because of how Jade multithreads (or not). The latter was built this way because on the face of it it seemed an appropriate approach (i.e. no apparent requirement to have separate Jade processes handling each new connection - would this result in 1266 exceptions with 5.1.8?).

Perhaps Krull or another guru could provide some useful, insightful comment here?

Cheers,

Eric in Otepoti

[ConvertFromOldNGs]

by Abduhl >> Wed, 7 Feb 2001 10:40:15 GMT

Perhaps when Roland submits his NFS he could ask for the documentation on TcpipConnection class to be improved. The documentation, particularly with regard to how Jade handles multiple connection objects (created as after listenContinuous). It's not clear how any multithreading (if any is done) when you have multiple connection objects belonging to the same process - what happens when one connection object is processing and a message arrives for another connection object? Does the second one have to wait for the first one to complete?

JADE employs a model were a single O/S thread per JADE process executes user logic for that process. If you use any of the asynch Connection methods, the actual open/close/send/receive is performed by a separate thread; however, the user defined asynch callback methods are invoked on the single thread associated with the user process. In essense that means one process handling multiple connections can only process one message at a time i.e. it is single threaded. If for some reason you code a doWindowsEvents(), display a message box or anything else that creates a windows message loop while in a callback method this can allow a re-entrant invocation of another asynch callback or even a windows event, event notification or timer event method; this form of nested processing is usually undesirable and best avoided.

It would be helpful to know more about this kind of thing. I know of one solution that has multiple applications (processes) each listening to separate ports (requiring a plethora of ports), and another which does a listenContinuous which results in multiple connections belonging to the same process (with the connection objects holding their own state and going in and out of transaction state when handling certain messages). Both of these solutions seem to work (i.e. in production without apparent problems). The former was built this way apparently because of how Jade multithreads (or not).

If this solution is used for JADE to JADE communications and you have control over both correspondents an alternative would be to use the 'reverse port' or 'port callback' approach I suggested earlier; this approach requires at most two ports and supports a process per connection model. I have used this approach in a non JADE system in the dim distant past (over 10 years ago) to workaround a different sort of environmental issue.

The latter was built this way because on the face of it it seemed an appropriate approach (i.e. no apparent requirement to have separate Jade processes handling each new connection - would this result in 1266 exceptions with 5.1.8?).

No, if you only reference the transient connection instances on the process that created them via listenContinuous or listenContinuousAsynch, then you shouldn't encounter 1266 exceptions. You will get this exception if you attempt to reference a connection on a different process (and you haven't disabled the exception).

[ConvertFromOldNGs]

by Hido Hasimbegovic >> Mon, 5 Feb 2001 3:16:37 GMT

Have you considered something a long the lines of the following: using a single communication or router process, which accepts connections, receives/sends messages and then passes them to 'worker processes' via an internal message queue?

Yes, although I was hoping to avoid the potential complexities and overhead of needing to code my own Server->Worker Heirachy.
But that seems like the best option since I have been thwarted in my original attempts to do something along the lines of 'connectionObject.listenContinuousThenStartAppMethodWithConnectionObject("My Schema","MyApp",ConnectionObject) '

Yes, although I was hoping to avoid the potential complexities and overhead of needing to code my own Server->Worker Heirachy.
But that seems like the best option since I have been thwarted in my original attempts to do something along the lines of 'connectionObject.listenContinuousThenStartAppMethodWithConnectionObject("My Schema","MyApp",ConnectionObject) '

Too bad it takes Jade about 30 mins to spin off a process, eh . I've had the same problem. Wouldn't it be nice if Jade supported light-weight worker threads which would be under programmer's control. I know there are a number of constraints that Jade faces due to its acrhitecture, but a bit of wishful thinking never hurt anyone.

Anyway, the way I've implemented a simple server/workers concept is as follows:
-start server with continuous listener,
-start a number of worker apps (create a pool)
-using notification, pass processing of any new connection to a worker app -if pool reaches critically low nr of free workers, start some more -conversly, if there are too many idle worker apps, shut down a few
-when notifying a worker app to process a request, pass reference to tcp object,
so that the worker app can send reply.

Works alright, although I'm not sure Jade has been designed to do these kind of things ...


Cheers,

Hido

[ConvertFromOldNGs]

by Abduhl >> Wed, 7 Feb 2001 10:43:48 GMT

-when notifying a worker app to process a request, pass reference to tcp object, so that the worker app can send reply.

Hido,

Are you succesfully passing connection references across process in JADE 5.1.7 or higher?
You would normally need to enable the 'dirty sharing of transients' option in the ini file or via the process method to allow this.

Works alright, although I'm not sure Jade has been designed to do these kind of things ...