On Tuesday, August 05, 2014 06:33:59 AM Martin Vaeth wrote: > J. Roeleveld <jo...@antarean.org> wrote: > >>No, it wouldn't, since jobs just finishing and wanting to report their > >>status cannot do this when there is no server. You would need a rather > >>involved protocol to deal with such situations dynamically. > >>It can certainly be done, but it is not something which can > >>easily be "added" as a feature: If this is required, it has to be the > >>fundamental concept from the very beginning and everything else has to > >>follow this first aim. You need different protocols than TCP sockets, > >>to start with; something like "dbus over IP" with servers being able > >>to announce their new presence, etc. > >> > > I think it's doable with standard networking protocols. > > Yes, you can "tunnel" such a protocol over existing protocols, > but "essentially" you must use a different one. > Unless you want a static setup (use server A, if that fail use > server B, and server A reports everything to server B) > it cannot be done in a simple way that you have only > one port open on the server: The client also needs a port open > to be informed about the "current" server. Even worse, you need > a "daemon" running for each client to handle this port. > In such a case, you might make each client its own server, > by spreading all changes to all clients immediately.
Not necessarily, the client listens on a port and the server connects to the clients it maintains. It then also knows when a client is dead and corresponding jobs have an issue. > > But, either you have a master server which controls everything. > > Or you have a master process which has failover functionality > > using classical distributed software techniques. > > This summarizes it quite good. > The concept of my "schedule" is to follow the first path (with the > advantage of being simple, having only one part, clients do nothing > while their "task" is runnning). > If you want to follow the latter, you need a rather different CLI > and a different protocol - which is practically everything "schedule" > consists of; so it is probably simpler to rewrite this from scratch. > As I said: It is not a "feature" you can easily add later on; it is a > fundamental decision you must choose from the very beginning. > When you are at it you should probably also encrypt the communication > and establish methods for authentification which is also something > I currently omitted in "schedule" for simplicity (although this might > be easier to add later on). I agree. "schedule" is good for most uses we might encounter. For the business case I have, I will need to write something myself. Thanks to this discussion we've been having, I now have a much better idea on how to approach this project. For that I am very thankful. -- Joost
