Hi Martin,

a fast first concept:

1) the service has to run on the remote server (perhaps as a demon ...)

2) when you start your client, it should launch a
- "find the pid of the sevice-process" on the remote server  (if not found, start a separate INDEPENDEND process)
- "connect as client" to the process found

3) it is all about inter-process-communication (like DDE, Mailslots, ....) or shared memory / using DLL features

Success, Uli

Hi Martin,

Here's an idea:

Maybe you can create your own userver.aps (Userver startup shell), which creates a detached instance of a service called "FACTORY", for example. The startupshell activates operation CREATEINSTANCE of this service, which then creates an instance of your service, and stores the handle to it in a component variable, for example. The client, when it first starts, activates the GETHANDLE operation of service FACTORY, which will give him the handle to your service. This handle he will use from then on to activate the operations of your service. This way, the service is instantiated when the userver starts, not when the client connects; so the handle count is always at least one, which means it will never be removed, until the userver itself is stopped.

Of course you must make sure there is only ever one userver running, by using the /max=1 flag. Otherwise you will have multiple uservers, each with his own instance of your service; you won't know which one will be activated...

Hope this helps,

Regards,

Etienne

Hi Martin,

I would think that if you have a userver (marked as max number=1) configured on your server, and a crafty use of asynchronous execution, you should then be able to have any client (re)connect to it.

The approach I would try on this would be to have a "launcher" service that runs the actual service you want, that first service would be remotely executes as well. going through its course but not killing any child instances.

Now for the fun bit, your problem is that a separate client would not have access to the instance that is left lying there... no matter, create a new instance of your lancher service, and within that one (that now runs on the app server) look for a previously instatiated version of your desired service, I reckon it should be there for the pickings...

As far as having control over the course of your service, it means you need it to have either Idle state at some point so that it allows for synchronous calls or you need it to check every once in a while for a control signal somewhere (that control signal could be held in a sleeping instance of another component held on the server as well to which the running process and the launcher service reattaches through $instances("SignalComponent"))...

It might be that the UTIMER component can be used on the service to allow it sleep time, from what i gather, you want a service that sits there and periodically ensure synchronisation, therefore you could do that through a timed action... not so sure about the generated asynchronous interrupt in a service but probably worth a shot.

The simplest way to get this communication going is probably through the database, via a control record that both the process and the client read and possibly update.

Process updates for progress and reads for stop signals and the client reads for updates status and sets control signals.

I hope this makes sense, those are only Monday morning ideas ... ;-)

Denis

_________________________________________________________

Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
- Rick Osborne