Binding Requests

Some pScheduler use cases require that the negotiations between hosts to arrange a measurement require that the connections involved originate on specific interfaces rather than the one that might be the network stack's default choice. The process of making that happen is called binding.

Addresses used for binding are specified as one of the following:

• Explicit IPv4 address (e.g., 198.51.100.68)
• Explicit IPv6 address (e.g., fc00::dead:beef)
• Resolvable host name (e.g., localhost)
• Fully-qualified domain name (e.g., myhost.example.com)

A diagram used to describe the binding operations before the feature was developed may be found here.

Binding With the Command-Line Interface

Request Origination

The command-line interface's task command can be directed to use an address other than the default when determining the participants or submitting the task to a pScheduler server. This is accomplished using the --bind switch.

For example, the command

pscheduler task --bind 203.0.113.86 rtt --source-node 203.0.113.99 --dest www.perfsonar.net

will instruct the command-line interface to bind to the address 203.0.113.86 when communicating with the assist server to determine the participants and the lead participant when submitting the task to the pScheduler node at 203.0.113.99.

Lead Origination

pScheduler can be instructed to do lead binding, where the lead participant uses an interface other than the default choice when administratively communicating with other participants. On the command line, adding the --lead-bind switch and a bind address will pass this directive to the lead participant.

For example:

pscheduler task --lead-bind ps1-internal throughput --source ps1-public --dest-node ps2-internal --dest ps2-public

will use a pair of internal addresses for all administrative communication. Not that this will have no impact on the measurement, which will be done between ps1-public and ps2-public.

Binding Programmatically

Tasks submitted to pScheduler by programs as JSON may supply a lead-bind pair indicating the interface that should be used by the lead participant when arranging the task with other participants. This value may be provided for single-participant tests but will be ignored.

For example:

{
    "schema": 1,
    "lead-bind": "198.51.100.202",
    "test": {
        "type": "idle",
        "spec": {
            "schema": 1
            "duration": "PT2S"
        }
    }
}

Archivers

The convention for archivers is to support and use a parameter named bind to name the interface which will be used as the source for its operation.

For example, this archive specification will instruct the RabbitMQ archiver to bind to bunny when connecting to rabbit-hole:

{
    "archiver": "rabbitmq",
    "data": {
        "bind": "bunny",
        "_url": "amqp://rabbit-hole/",
        "routing-key": "carrots"
    }
}

Some archivers may not support binding at all and others may use a different name if merited. Consult the documentation if unsure.