Tool Integration Guidelines

This is a list of things a tool (the program doing the measurement, not the pScheduler plugin) should provide to make it easier to integrate with pScheduler.

All Tools

List of Permissions. A list of any special permissions beyond those of a normal user required for the tool to make its measurement, and under what circumstances. (E.g., ping(8) requires superuser permissions when some of its switches are present on the command line.)

Unixy Behavior. Tools should produce results on the standard output, diagnostics and debug on the standard error and exit zero if successful and nonzero on failure. Multiple non-zero exit statuses that can be used to distinguish incorrect invocation vs. a failed measurement vs. other problems is helpful.

Machine-Readable Output. This can be available using a switch if the usual output is intended for humans to read. JSON is preferred, but anything that can be parsed by a Python program with easily-available modules is fine. We’ve written custom parsers for the plain output of programs before, but we'd prefer not it.

Address and Port Control. Tools should be able to bind to a specific interface, address and port depending on what's applicable for the measurement.

Tools for Multi-Participant Measurements

One-Shot Mode. Where a daemon or server has to be run on the far end, it should have a mode where it services one client request and then exits successfully.

Authentication. (Optional but desirable.) The far-end service should have a facility where it can be given a key to expect in the payload from a near-end client in deciding whether or not the request should be serviced. The one-shot mode described above should keep running until it has serviced a request with the right key.