From the Iperf web site:Currently BWCTL wraps Iperf by actually executing the iperf command line program on the system. The bwctl client application works by contacting a bwctld process on the remote system and on the local system to requests that those daemons perform a specific Iperf test between them. bwctld manages and schedules the resources of the host it runs on. Therefore, it is necessary to contact a daemon on the local host as well as the remote host to ensure more than one Iperf process does not happen at the same time on the either host. A more detailed description of the architecture is available in the architecture documentation.
Iperf is a tool to measure maximum TCP bandwidth, allowing the tuning of various parameters and UDP characteristics. Iperf reports bandwidth, delay jitter, datagram loss.
The bwctl client is used to request the type of Iperf test wanted. Furthermore, it requests when the test is wanted. bwctld either responds with a tentative reservation or a test denied message. Once bwctl is able to get a matching reservation from both bwctld processes (one for each host involved in the test), it confirms the reservation. Then the bwctld processes run the test and return the results. The results are returned to the client from both sides of the test. Additionally, the bwctld processes share the results from their respective sides of the test with each other.
BWCTL is used to enable non-specific Iperf tests to a host without having to give full user accounts on the given system. Users want the ability to run Iperf to determine the achievable or available bandwidth between a pair of hosts. It is often useful to test to multiple points along a network path to determine the network characteristics along that path. Typically, users that want to do this path decomposition have to directly contact the network/system administrators that control the hosts along the path. The administrator needs to either run half of the test for the user or give them a user account on the host. Also typically, network paths of interest are usually controlled by multiple administrators. These hurtles have made this kind of testing difficult in practice.
BWCTL was designed to help with this problem. It allows an administrator to configure a given host as an Iperf endpoint that can be shared by multiple users without concern that those users will interfere with each other. Specific policy limits can be applied to specific users, and individual tests are scheduled so they will not interfere with each other. BWCTL allows the administrator to classify incoming connections based upon a user name and AES key (generated by a pass phrase) combination or alternatively based upon an IP/netmask. Once the connection is classified, the bwctld can determine the exact type and intensities of Iperf tests that will be allowed. (More details on the policy controls can be found in the bwctld.limits(8) manual page.)
A basic build procedure would be:
Please report any build problems to bwctl-users@internet2.edu.% gzip -cd bwctl-$VERS.tar.gz | tar xf - % cd bwctl-$VERS % ./configure --prefix=/inst/root # --prefix is only needed if you don't like the default (/usr/local on most systems) % make % make install
bwctld.conf:
Used to configure basic operation of the daemon such as server listening
port, the path for iperf, and error logging. For a detailed description
of the options available see the bwctld.conf(8)
manual page.
bwctld.limits:
Used to configure the policy limits for the daemon. There are two parts
to this policy. 1) authentication. 2) authorization. The authentication
is done by assigning a class to each new connection. Each class has a set
of limits associated with it. The classes are hierarchical, so a connection
must pass the limit restrictions of the assigned class as well as all parent
classes. For a detailed description of the options available see the
bwctld.limits(8)
manual page.
bwctl.keys:
Used to associate identities with AES keys. These identities are then
mapped to a class by the bwctld.limits file. For a more detailed
description see the
bwctld.keys(8) manual
page.
It is possible to run the daemon without a config file directory if enough command-line options are specified, but it is easier to use a config file.% bwctld -c /inst/root/etc
To see all the available options:
More details on running the daemon as well as a complete description of the command-line options is available from the bwctld man page.% bwctld -h
The -c option indicates that the targethost should be an iperf client (sender). The -s option indicates the targethost should be an iperf server (receiver). Currently bwctl only supports one of these options at a time, with the other host assumed to be the localhost.% bwctl [options] [-c|-s] targethost
To get the list of available options use:
More details on running the client application with a complete description of all command-line options is available from the bwctl man page.% bwctl -h
$Id: index.html,v 1.7 2004/02/16 23:00:53 boote Exp $