Daemon - crazedsanity/WebCron GitHub Wiki

This is the system that spawns processes and monitors them. Changes from the application server are handled, including termination of running processes.

Installation

Creating a new instance of a daemon involves a few things.

How To Daemonize

Consider these options:

Real-Time Updates from the Application Server

Consider these options:

  • direct TCP?
  • HTTP polling?
  • ... other?

Get the Code

Create a clone of the WebCron application on the machine that the daemon will run on. Take a look at Creating a Local Repository for some pointers on ensuring internal stability.

It may seem like overkill, but this is the surest way that the daemon will be running the appropriate code. To avoid running into development bugs, consider creating a fork of the repository, or a local copy, to pull from.

Create the Configuration

Once an API key has been generated, get a copy of the server's conf/config.xml file, and put it into the daemon's conf/ directory (same name). Remember to update the daemon's api-key value properly, as failing to do so will cause messages to be rejected (changing it will allow previously-rejected messages to succeed), or to be logged incorrectly (NOTE: the server should do some sanity checking to ensure the connecting daemon isn't accidentally using the wrong key).

Start the Daemon

TODO: create this section!

Technical Tidbits

Communication with Process Managers

This is still... in the works.

The daemon could be communicating to it's sub-processes by connecting pipes to the input pipes of it's sub-processes. I'm not sure how this works... check out this example of connecting input/output pipes in PHP.

Communication with the Application Server

NOTE: using HTTP/S is the current method of communication for the sake of simplicity and fewer requirements; should a better and still simple method present itself, it would of course be considered.

All connections are HTTP or HTTPS based for simplicity. An API URL is assigned to each daemon on a server. There is no defined reason for having multiple daemons running on a single server, but there is nothing that limits such a thing from happening.

  • the "listener"

This connection is constant, uses HTTP GET, and reconnects as soon as the old connection goes away. The application server utilizes long polling to maintain the connection and minimize reconnects. This should happen no more that once per second.

Only one of these connections should exist per daemon. The application server determines that a given daemon is running so long as one of these connections is alive (requires that the server terminate the script if the daemon's connection is canceled).

  • the "updater"

This connection occurs as frequently as necessary, to send updates from running processes, and utilizes HTTP POST messages on the same API. This message contains all updates available at the moment the connection is established.

Multiple of these connections can exist per daemon, occurring as often as necessary, and containing one or more messages. In the event that an update does not receive an acceptable response (eg. an error response is given), this update will be included in a subsequent connection.