22.5 Multiple-Client Driver

Team-FLY

A single host, even though it is running multiple threads or processes, may not be able to offer a large enough load to a web server to measure its capacity. Your implementation should have the following features to support running multiple loading clients .

Be able to coordinate the clients to send at the same time.
Be able to collect and analyze combined statistics from all clients.
Be sure that the traffic generated by the clients for synchronization and statistics does not interfere with the traffic being measured.

This section discusses a client-driver design that can be used to put a coordinated load on a server and gather statistics with minimal interference with the measurements.

The design involves two programs: a control driver and a client driver. The control driver controls multiple copies of the client driver and gathers and analyzes statistics from them. The client driver takes an optional port number in addition to the command-line arguments specified in Section 22.4. Without the optional port number, the multiple-client driver behaves like the single-client driver. If the optional port is given, the client communicates with the control driver through this port. The client starts by listening for a connection request on the optional port before loading the server and sends statistical data back over the connection. A synchronization mechanism is set up so that all clients start almost simultaneously and do not send their statistics over the network until all other clients have completed communication with the server.

Copy your singleclientdriver.c into multipleclientdriver.c and compile it as multipleclientdriver . Modify multipleclientdriver to take an additional optional control port number as a command-line argument. If this optional argument is present, multipleclientdriver does the following.

Wait for a connection request from the control host on the control port.
When this request arrives, send the number of child processes to the control host as a 32-bit integer in network byte order.
Create the child processes to load the host.
When loading completes, send a single byte to the control host and wait for a 1-byte response.
When a response from the control host arrives, forward data to the control host in an appropriate format and exit. A format for the data is given below; it includes a special record to indicate that all the data has been sent.

Notice that multipleclientdriver acts as both a client of the server being tested and a server for the control host.

Write a program called controldriver.c to control multipleclientdriver . The first command-line argument of controldriver specifies the port number for communicating with multipleclientdriver . This is followed by one or more command-line arguments specifying the names of the hosts running multipleclientdriver .

The controldriver program does the following.

Establish a connection to each of the hosts specified on the command line, using the given port number. Keep the file descriptors for these connections in an array.
Read a 4-byte integer in network byte order from each connection. Each integer specifies the number of child processes on the corresponding host. Save the integers in an array.
For each connection, read a byte for each process corresponding to that connection. (When all the bytes have been read, all the processes have finished loading the server.)
After receiving all the bytes from all connections, do the following for each process on each connection,
1. Send a single byte. (This tells a process to start sending its data.)
2. Read data until no more data is available from that process. The event type EVENT_TYPE_DATA_END can be used to signify the end of data from a single process.
After receiving all data, analyze and report the results.

One of the important design decisions is the format for the data that multipleclientdriver sends to controldriver . If multipleclientdriver sends raw data, then controldriver can dump the data to a single file for later processing or it can perform analysis itself.

Since controldriver does not necessarily know how much information will be sent from each process, it is simplest if the data is sent in fixed-length records. The controldriver program can store these in a linked list as they come in or write the data to a file. A possible format for a data record is the following.

 typedef struct {    int_32 time_sec;    int_32 time_nsec;    int_32 con;    int_32 req;    int_32 pid;    int_32 serv_pid;    int_32 serv_tid;    int_32 serv_msgnum;    int_32 event; } con_time_t;

All the values in this structure are 4-byte integers in network byte order. Each record represents an event that occurred at one of the multipleclientdriver processes. The first two fields represent the time at which the event took place. These values represent wall clock times on the individual multipleclientdriver hosts, and only differences are relevant since the clocks on these hosts are not assumed to be synchronized. The con and req fields represent the connection number and request number for a given process of multipleclientdriver . Different processes are distinguished by the pid field, which gives the process ID of the process generating the data. The value here is important only in distinguishing data from different processes, since all the processes of a given multipleclientdriver send concurrently. The next three fields are the values returned to the multipleclientdriver from the server being tested. The last field is an indicator of the event. Some possible types include the following.

 #define EVENT_TYPE_PROCESS_START 0 #define EVENT_TYPE_CONNECTION_START 1 #define EVENT_TYPE_CONNECTION_END 2 #define EVENT_TYPE_SERVER_LOAD_DONE 3 #define EVENT_TYPE_CLIENT_ALL_DONE 4 #define EVENT_TYPE_CLIENT_FIRST_DATA_SENT 5 #define EVENT_TYPE_CLIENT_LAST_DATA_SENT 6 #define EVENT_TYPE_SERVER_DATA_REQUEST_START 7 #define EVENT_TYPE_SERVER_DATA_REQUEST_END 8 #define EVENT_TYPE_DATA_END 9

The controldriver process can either keep a linked list of events for each multipleclientdriver process or it can store information about which connection the data came from in a single linked list.

22.5.1 Alternative multiple-client design

An alternative design puts all the parameters in the control program. The multipleclientdriver program takes a single command-line argument: the port number for communicating with the control driver. After establishing the connections, the control driver sends its command-line arguments to each multipleclientdriver . Since both string (hostname) and numeric data (everything else) are to be communicated, a format for this information would need to be specified. If all machines were ASCII-character based, a string that the client would read one character at a time could be sent. An alternative would be to send all data in numeric form (network-byte-ordered integers) by sending the IP address of the server rather than its name .

Since the control driver knows the number of processes on each client, the client driver does not need to send any information back to the control driver until it is ready to send statistics.

The control driver would need more command-line arguments or a configuration file containing the name and port number of the server as well as the number of processes, connections, requests and request size . A configuration file could have one line for each client driver, specifying the name and port number of the client driver as well as the number of processes, connections, requests and connection size. The control program takes the server name, port and configuration file name as command-line arguments. The same configuration file can be used to put loads on different servers.

Team-FLY