Troll: A Program to Garble UDP Packets

The transport protocol is designed to handle various kinds of networks. To simulate different network characteristics, we will provide you a program called troll. Instead of sending packets directly to a destination socket, you should send them to troll with the destination socket's address in the first sixteen bytes of the packet. (This implies that you have to provide space for these headers in your packet formats in the transport layer when using troll). Based on the configuration parameters entered to control error rates, troll will forward packets to their destination after randomly discarding, garbling, delaying and/or duplicating them. (See the manual page of troll.)

If you want absolute delay in your packets, you must set the option "-r" when using troll. Note that the times are not accurate in Solaris. When setting delays in troll in 1 msec intervals, you may observe delays of about 10-20 msec. This is actually normal.

Note that when packets are held in the buffers of troll and your application stops sending packets, these packets may not get delivered and be stuck in the buffers. The problem is caused by the implementation of select in Unix. When select is used in a blocking mode on a socket, it will only return when there are some packets arriving at the socket. This property seems to block signals sent from select to the calling process. As a result, packets in the buffer of select will not leave until some new packets arrive.

The workaround is to have totroll and fromtroll running at the same time as your program. You can set up totroll to send data at a relatively slow rate continuously, say every 100 ms, through troll to fromtroll. The new packets sent to troll will force it to clear its buffer periodically.

The object codes of troll are available for the following platforms (download and save the files to your local computer first). Currently, the troll program was compiled to allow a maximum delay of 60 seconds for each packet and a maximum of 500 pending packets in its queue.

1) Solaris Sparc

2) Linux X86.

You should test the troll program using the source codes of fromtroll.c , totroll.c and troll.h. For using the troll process with Java code, see  the methods in this file structReadMethods.java.  Note that you can have every process communicating with a single troll process in the system, and that the troll process can be located in any computer. The following is an example of the steps taken to test troll.

a) On machine eesn11.ews.uiuc.edu, start troll to communicate on port 10240 as follows.

troll -r -se 10000 -g 0 -m 0 -x 0 10240

This will run troll in the foreground, allow reordering of packets (in order to delay them), delay packets by an exponential distribution with an average of 10 seconds, no garbled packets, no dropped packets, and using UDP port 10240.

b) On machine eesn12.ews.uiuc.edu, start fromtroll to listen on port 10230.

fromtroll 10230

c) On eesn11.ews.uiuc.edu, start totroll to send a short message via troll to fromtroll on eesn11.ews.uiuc.edu as:
totroll eesn11.ews.uiuc.edu 10240 eesn12.ews.uiuc.edu 10230

You should see the messages sent and the responses returned. By varying the parameters in troll, you will be able to see message dropped, corrupted and duplicated. You can see the traces generated by troll when its parameters were entered interactively.

Acknowledgment: We like to thank Prof. Larry Landweber for providing us with the source code of troll.