A Network Monitoring and Simulation Tool

A Network Monitoring and Simulation Tool

Most online games are developed under ideal conditions, on a high bandwidth local network with extremely low latency. In contrast, online games are typically played in low bandwidth, high latency environments, with unpredictable network behavior between machines. This Gem describes a Windows-based simulation tool called NetTool that you can use to make a LAN behave more like the Internet. Complete source code and Win32 binaries are on the accompanying CD.

Interface

Figure 1 shows a picture of NetTools interface. The top section defines a set of filters. Each filter describes the behavior of the network between two (IP address, port) pairs. TCP filters, being connection-oriented, allow communication in both directions, so only one filter is required between any two hosts. UDP filters are one-way; the Add reverse button will take the currently selected filter and create a new one with the endpoints reversed. This is useful in the common case where the hosts use the same port to send and receive data.

Figure 1. NetTools interface.

NetTool simulates network latency on a per-packet basis according to a Gaussian distribution. The interface allows you to set the mean and variance of each filters latency distribution.

There are several other controls available on each filter. Incoming packets are only forwarded when the Enabled box is checked, allowing you to selectively restrict traffic from individual hosts. Checking the Listed box causes incoming packets to be displayed in the large list box in the lower right. The UDP Options settings apply only to UDP filters, and are described later.

The title bar displays all of the IP addresses assigned to the machine running NetTool.

Network monitoring

As packets arrive, NetTool dispatches them according to the settings of the filters that they match. If the Show packets box is checked, a summary of each packet is displayed in the list box in the lower right on the interface. This shows the packets arrival time, payload size, incoming and outgoing addresses, and the action that was taken by NetTool. The action will be one of the following:

Sent immediately: No extra latency is required for this packet, so its sent right away.

Delayed X ms: The network simulation requires that the packet be delayed before being forwarded. The amount of delay is a combination of the filters latency settings, and the host bandwidth simulation (see below).

Dropped: The packet was not forwarded. This occurs only for UDP packets when the filters Packet loss setting is nonzero.

Reordered: The packet was sent before another packet that arrived previously. This can only occur for UDP packets when the Reordering setting is nonzero.

Duplicated: The packet was sent twice. This occurs only for UDP packets when the filters Duplication setting is nonzero.

Wait for connect: For a TCP filter, data arrived before the remote connection completed. It will be sent as soon as the connection succeeds.

If the Log to file box is checked, the same summary information will be logged to the file log.txt.

TCP Simulation

TCP is a reliable, stream-based protocol: data arrives in the order it was sent, in arbitrarily sized chunks. NetTool appends all incoming data on a filter to a single queue. It then polls the queue, forwarding as much data as the senders and receivers bandwidth simulations will allow.

Several subtleties arise in NetTool because of TCPs connection-oriented nature. For example, data can arrive from the sender before the connection to the receiver has completed, or the sender can shut down the connection before previously sent data has been forwarded. These cases are accounted for, and should be transparent to applications.

UDP Simulation

UDP is message oriented, meaning that data arrives in the same chunks in which it was sent. UDP is also unreliable, meaning that individual messages may be lost in transit, arrive out of the order in which they were sent, or even arrive multiple times. On a local network, UDP packets are almost never lost, but on the Internet, packet loss is common.

NetTool drops packets with a probability given by the Packet loss box. These packets are simply thrown away, much like a router on the Internet might do under a heavy load.

If a packet is not dropped, it may be duplicated (sent twice), with a probability equal to that shown in the Duplication box. The latency model is applied to the two duplicate packets independently. If reordering is enabled, its possible that the duplicated packets will not arrive one after the other.

Packet reordering will only occur in certain circumstances. Suppose two UDP packets, A and B, arrive on the same port. The latency simulation is applied to each packet independently, causing A and B to be scheduled for transmission. If, as a result, A is scheduled before B, no reordering will occur. However, if B is scheduled before A, NetTool will preserve this ordering with the probability given in the Reordering setting. In order to force reordering to occur for testing purposes, its useful to introduce latency with a high variance to make this second scenario more probable.

Host bandwidth simulation

In addition to arising from network delays, latency is also induced at the endpoints of a connection by the available bandwidth. For example, on a 300 bps modem connection, it takes an entire second just to send 30 bytes (assuming 8 bits per byte, plus a start bit and a stop bit). In the lower left section of the interface, you can set the bandwidth available at each host. The send and receive bandwidth can be set separately, as this is actually a common case with 56k modems (which can only upload at 33.6k), and with asymmetric DSL connections. Several predefined bandwidth settings are available on buttons below the bandwidth sliders; these values are only approximate.

NetTools bandwidth calculations take into account the size of the header attached to each packet. For UDP, this is 28 bytes (20 bytes IP header, 8 bytes UDP header), though this can be reduced to a simulated 7 bytes if Uses PPP is checked, as PPP compresses the IP header. For TCP, the header would normally be 40 bytes, but most slow consumer connections use VJ header compression that reduces the size to about 8 bytes. In addition, many modems have optional compression, which can be simulated by setting a compression percentage in the lower left corner. This bandwidth simulation is somewhat simplistic, but it is sufficient to produce the approximate behavior of a client connection.

Conclusion

NetTool is a convenient way to simulate consumer Internet connections on a LAN. It is particularly useful for stress testing under poor network conditions; an ideal use would be testing an implementation of reliable communication on UDP. Please forward any improvements you make to the author, so that they may be shared with others.