| 1 |
J. Roeleveld <joost@××××××××.org> wrote: |
| 2 |
>> |
| 3 |
>>No, it wouldn't, since jobs just finishing and wanting to report their |
| 4 |
>>status cannot do this when there is no server. You would need a rather |
| 5 |
>>involved protocol to deal with such situations dynamically. |
| 6 |
>>It can certainly be done, but it is not something which can |
| 7 |
>>easily be "added" as a feature: If this is required, it has to be the |
| 8 |
>>fundamental concept from the very beginning and everything else has to |
| 9 |
>>follow this first aim. You need different protocols than TCP sockets, |
| 10 |
>>to start with; something like "dbus over IP" with servers being able |
| 11 |
>>to announce their new presence, etc. |
| 12 |
> |
| 13 |
> I think it's doable with standard networking protocols. |
| 14 |
|
| 15 |
Yes, you can "tunnel" such a protocol over existing protocols, |
| 16 |
but "essentially" you must use a different one. |
| 17 |
Unless you want a static setup (use server A, if that fail use |
| 18 |
server B, and server A reports everything to server B) |
| 19 |
it cannot be done in a simple way that you have only |
| 20 |
one port open on the server: The client also needs a port open |
| 21 |
to be informed about the "current" server. Even worse, you need |
| 22 |
a "daemon" running for each client to handle this port. |
| 23 |
In such a case, you might make each client its own server, |
| 24 |
by spreading all changes to all clients immediately. |
| 25 |
|
| 26 |
> But, either you have a master server which controls everything. |
| 27 |
> Or you have a master process which has failover functionality |
| 28 |
> using classical distributed software techniques. |
| 29 |
|
| 30 |
This summarizes it quite good. |
| 31 |
The concept of my "schedule" is to follow the first path (with the |
| 32 |
advantage of being simple, having only one part, clients do nothing |
| 33 |
while their "task" is runnning). |
| 34 |
If you want to follow the latter, you need a rather different CLI |
| 35 |
and a different protocol - which is practically everything "schedule" |
| 36 |
consists of; so it is probably simpler to rewrite this from scratch. |
| 37 |
As I said: It is not a "feature" you can easily add later on; it is a |
| 38 |
fundamental decision you must choose from the very beginning. |
| 39 |
When you are at it you should probably also encrypt the communication |
| 40 |
and establish methods for authentification which is also something |
| 41 |
I currently omitted in "schedule" for simplicity (although this might |
| 42 |
be easier to add later on). |
Archives