Re: Multi-client approaches

in reply to Multi-client approaches

I built a system similar in design to Joost's. The only siginficant difference was that once the client was assigned to a worker, the "server" got out of the way and let the two communicate directly. In my case each client could have had multiple workers (implemented as virtual machines) all on the same physical machine. The server was perl, the workers were under control of a perl executive, and the clients were a Java/C combination.

HTH

Comment on Re: Multi-client approaches

Replies are listed 'Best First'.
Re^2: Multi-client approaches by Joost (Canon) on Feb 01, 2008 at 01:29 UTC
The only siginficant difference was that once the client was assigned to a worker, the "server" got out of the way and let the two communicate directly. I never considered doing that for my project, mainly because the jobs were usually (but definitely not always) finished within a fraction of a second - somewhere between 1 and 0.05 seconds is typical - and multiple clients can - and will, if the job queue is long enough - request the same job (which might be running or queued already). Putting all the coordination in the server made the clients and the workers very simple. Having all the synchronization in a single-threaded single process made the server relatively simple too. "What should it profit a man, if he should win a flame war, yet lose his cool?"	[reply]

Replies are listed 'Best First'.

Re^2: Multi-client approaches
by Joost (Canon) on Feb 01, 2008 at 01:29 UTC

The only siginficant difference was that once the client was assigned to a worker, the "server" got out of the way and let the two communicate directly.

Putting all the coordination in the server made the clients and the workers very simple. Having all the synchronization in a single-threaded single process made the server relatively simple too.

"What should it profit a man, if he should win a flame war, yet lose his cool?"

[reply]

In Section Seekers of Perl Wisdom