Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 4 of 4 total
Thread Communication Between Clients for Distributed Processing
Thu, Nov 9 2006 5:20 PMPermanent Link

"Johnnie Norsworthy"
I am setting up a little DBISAM Client Server database that will have a
bunch of client "worker" machines updating tables all day long.

I need to come up with a reliable and fast system for controlling the worker
machines. A main computer (not the server) would need to have ultimate
control over all the worker computers. They need to know how to do things
like:

How many workers are out there and what are their names?
Do "this" now.
Add this to your list of things to do
Stop doing that.
Remove this from your list of things to do.
What have you done (log report)?
What are you doing now?

It would be nice if I could just control this by sending messages to the
DBISAM server such as by add messages to a table, but I am worried about the
speed of such a solution. It seems that there would require constant polling
by the worker computers and that would be detrimental to the database. The
primary control I need is to stop the process occasionally.

I could have all the worker machines record their information to a table
when they first connected so that I could know their IP address and be able
to start a socket communication with them, which I think would be the
fastest way to control the machines.

Any idea? I'm not creating SETI here but I can't get my noodle around the
best solution. Sometimes when I write these long messages, I come up with my
own idea, but here I am at the end of the message and I haven't yet.

Thanks,
Johnnie

Thu, Nov 9 2006 5:40 PMPermanent Link

Steve Gill
Hi Johnnie,

<snip>
> Any idea? I'm not creating SETI here but I can't get my noodle around the
> best solution. Sometimes when I write these long messages, I come up with my
> own idea, but here I am at the end of the message and I haven't yet.

Have you had a look at the Real Thin Client SDK
(www.realthinclient.org)?  I'm using it to send messages between
applications so I think it may be what you need.

Regards,

SteveG
Thu, Nov 9 2006 6:17 PMPermanent Link

"Johnnie Norsworthy"
"Steve Gill" <v8steve_removethis_@gmail.com> wrote in message
news:A37D94EA-A887-4E11-9157-036FB90D73B4@news.elevatesoft.com...
> Hi Johnnie,
>
> <snip>
>> Any idea? I'm not creating SETI here but I can't get my noodle around the
>> best solution. Sometimes when I write these long messages, I come up with
>> my own idea, but here I am at the end of the message and I haven't yet.
>
> Have you had a look at the Real Thin Client SDK (www.realthinclient.org)?
> I'm using it to send messages between applications so I think it may be
> what you need.

I have a license for it I got when he gave away a bunch during the Turbo
downloads, but I haven't looked into it much. Too little time to learn much
new right now. The good thing about getting RTC was that I'll need it for
the new RemoteTools when it becomes available.

-Johnnie

Thu, Nov 9 2006 6:29 PMPermanent Link

"Johnnie Norsworthy"
As an absolute minimum I will need to be able to stop remote computers from
performing a type of task.

So if I have a  tiny table on the server:

Table: TaskControl
Column: TaskType: Integer
Column: Stopped: Boolean;

Then the client machines can check periodically, maybe once a minute, if the
flag is set and abort that operation if it is.

Would this table certainly be cached and not slow down the process too much?
Most access should be on a LAN.

I could make a server function that basically sets/reads a boolean array
value on the server if that would be better. When the server starts the
array would be all false and then a server procedure could be used by the
controller computer to turn them on or back off. A worker machine would just
use that function to test to see if they were enabled. So this would be a
very easy and small server function. Generally, how fast should a round trip
like this on a LAN? I hate to slow the process too much by asking if it
should be running all the time.

-Johnnie

Image