Re: [Clockwork-developers] Implementation of a decentralized schedule

[Shawn M. <smc...@ei...>]

This one time, at band camp, C. Brian Hill wrote:
>=20
> 1) Allow the client to have a predetermined list of servers (possibly in a
> configuration file), and have it make TCP connections to each server as
> needed, sending all communications through these servers.  This isn't
>=20
> 2) Have the client broadcast on its local networks (UDP), and autodiscover
> servers.  This might work, especially, if we make each of the servers know
>=20
> 3) Implement two methods of communication:  a protocol for the client to
> directly request information from the servers (this would be done using
> unicast TCP connections), and then the usage of IP multicast for the send=
ing
> of event-related information between the servers and the clients.  This
> would keep us from having to use broadcasts (to start up the client, meth=
od
> 1 or 2 could be used), and make it easy for all the servers to know about
> event that occur.
>=20
> 4) Use broadcasts for communications which apply to more than one server,
> and use unicast TCP for point-to-point communication.

Option three is the least heinous, but still suffers from "I missed a
packet, and now I need to request the entire state of the database from
you".

If somebody says "show me the state of the job flow on all servers", we
don't want that to require connecting to dozens of machines to transfer
the entire job database.  Central management is going to be critical
to allowing one person to see the enterprise-wide state of a complex
application.  Assuming we want to support things as complex as, say,
Chronos.