- 6.1 About Ethernet
- 6.2 About Hubs, Switches, and Routers
- 6.3 About TCP/IP
- 6.4 About Packets
- 6.5 About Remote Procedure Calls (RPCs)
- 6.6 Slop
- 6.7 Observing Network Traffic
- 6.8 Sample RPC Message Definition
- 6.9 Sample Logging Design
- 6.10 Sample Client-Server System Using RPCs
- 6.11 Sample Server Program
- 6.12 Spinlocks
- 6.13 Sample Client Program
- 6.14 Measuring One Sample Client-Server RPC
- 6.15 Postprocessing RPC Logs
- 6.16 Observations
- 6.17 Summary
- Exercises
6.13 Sample Client Program
The client program, shown in Figure 6.14, takes command-line arguments and sends one or more RPCs to a specified server and port, repeated and spaced out in time in a stylized way.
Multiple instances of client4 can be launched in the background so that they overlap in time on a single machine, and of course multiple instances can be run from several different machines. Instances of server4 and client4 can also run on the same machine, but will not use the network for local communication; for this degenerate case, the kernel network code moves message bytes in RAM.
Figure 6.14 Sample client program
The command-line arguments to client4 allow specifying Rep repetitions of the pair of actions
<send K RPCs, wait M msec>
The first RPC of a burst of K is specified by its method and initial key/value data. Either field can be padded with pseudorandom data to a specified byte length. Subsequent RPCs in a burst keep the method and base strings but supply possibly incremented keys/values. Within a burst, each RPC is sent as soon as the previous one returns a response, but not before.
The client4 program takes a set of command-line parameters that form a little language:
./client4 server port [-rep number] [-k number] [-waitms number] [-seed1] [-verbose] command [-key "keybase" [+] [padlen]] [-value "valuebase" [+] [padlen]]
The write, read, and delete commands require a key, and the ping and write commands require a value.
-rep |
Says to repeat the outer loop some number of times. |
-k |
Says to repeat the command some number of times (the inner loop) and then wait before continuing the outer loop. |
-waitms |
Says how long to wait (in milliseconds) after each burst of k commands. |
-seed1 |
Says to seed the random number generator for padding bytes to exactly the value 1, allowing reproducible pseudorandom values. |
-verbose |
Prints a little about each request and response message. |
-key "keybase" [+] [padlen] |
Specifies a base character string that is optionally incremented and optionally padded with random characters. In the presence of -rep and -k repetitions, “+” indicates incrementing the base string, and padlen gives the padded length. |
-value "valuebase" [+] [padlen] |
Uses the same algorithm. |
For example,
./client4 target_server 12345 -k 5 ping -value "vvvvv" + 10
sends five ping commands to target_server:port, with value strings such as
vvvvv_0u5j vvvvw_trce vvvvx_qxol vvvvy_1bv3 vvvvz_dg1w
where the + specifies incrementing v w x y z in the base string, and the 10 specifies padding with random characters out to 10 characters total. Incrementing increases the low character of the base string by 1, wrapping 9 to 0, z to a, and Z to A, carrying into higher character places as needed (the next base value above would be vvvwa). Incrementing is most useful for keys and padding is most useful for values.
The individual commands are defined in a little more detail here.
ping [-value “valuebase” [+] [padlen]]
Sends an RPC request to the specified server:port containing RPC marker, RPC header, and optionally RPC data containing the specified value. The server responds with the same data.
write }-key “keybase” [+] [padlen] }-value “valuebase” [+] [padlen]
Sends an RPC request to the specified server:port containing RPC marker, RPC header, and RPC data containing the specified <key, value> pair. The server saves each <key, value> pair and responds with a status code, typically SUCCESS.
read }-key “keybase” [+] [padlen]
Sends an RPC request to the specified server:port containing RPC marker, RPC header, and RPC data containing the specified key. The server responds with the matching value and a status code, typically SUCCESS.
delete }-key “keybase” [+] [padlen]
Sends an RPC request to the specified server:port containing RPC marker, RPC header, and RPC data containing the specified key. The server deletes each matching <key, value> pair and responds with a status code, typically SUCCESS.
stats
Sends an RPC request to the specified server:port containing RPC marker, RPC header, with no RPC data. The server responds with an arbitrary status string and a status code, typically SUCCESS. For server4, the status string is a text version of the spinlock histogram described earlier—32 counts separated by single spaces.
reset
Sends an RPC request to the specified server:port containing RPC marker, RPC header, with no RPC data. The server removes all its <key, value> pairs and responds with a status code, typically SUCCESS.
quit
Sends an RPC request to the specified server:port containing RPC marker, RPC header, with no RPC data. The server responds with a status code, typically SUCCESS, and exits immediately afterward.
The client4 program prints the observed round-trip time for the first 20 RPCs it issues. At the end, it prints a log2 histogram of those times, plus total RPCs, total msec elapsed, total MB transmitted and received, and RPC messages transmitted and received per second. In a datacenter system, this is the kind of information that would be displayed on a dashboard web page.