ONL Tutorial

The ONL Tutorial

Tutorial >> Router Plugins

TOC

Sending a Message to a Plugin

Plugin instances can receive and respond to messages. At the moment, the messaging system is rudimentary and involves sending a command consisting of a sequence of integers and receiving a reply that is another sequence of integers. The first integer of a command message is the operation code, and the remaining integers are its arguments. A message can have atmost 10 integers.

For example, the delay plugin pdelay:3579 returns the following values for all commands:

Packet count (number of packets passed to the plugin)
Drop count (number of packets dropped by the plugin)
Forward count (number of packets forwarded by the plugin)
Maximum queue length (maximum number of packets in the queue)
The current delay time (msec)
The callback period of the plugin (msec)

It responds to the following commands by replying with the above information and additionally doing the following:

Code	Command	Arguments
0	Return counts (debug mode)	None
1	Return counts	None
2	Set the delay	Delay (msec)
3	Reset all counters	None
4	Change the callback period	msec

All other commands (code 5 or larger) will do nothing extra and are equivalent to a code of 1. The first command (code 0) exists for historic reasons.

Fig. 1. Sending a Message to a Plugin Instance.

Fig. 1 shows how to send a command to the pdelay plugin instance 0 at egress port 1.2. The recipe is:

Window/Panel	Selection/Entry	Explanation
Port 2 Plugins	Edit => Send Command to Instance	Pop up Send Command dialogue box
Send Command	Command ID: 2	Code 2: Change the delay value
	Parameters: 25	Set the delay to 25 msec

A reply message dialogue box will pop up showing the reply message.

Fig. 2. Traffic Bandwidth and Queues
(25 msec Delay of n1p2-n2p2 packets).

Fig. 2 shows the result of shortening the delay of TCP ACK packets going back to n1p2 from 50 msec to 25 msec. The traffic is still being generated by the runClients script that begins three TCP flows staggered 10 seconds apart with a starting order of n1p2, n1p3 and n1p4. The bandwidth chart shows that the flows start at T = 2,450, T = 2,461 and T = 2,470 respectively. The incremental bandwidth chart in Fig. 2 shows the equal bandwidth sharing of the 100 Mbps link as each source starts sending traffic.

The Queues chart shows the sawtooth shape of the queues expected with TCP flows. But since only the ACK packets going back to n1p2 are delayed, the period of the sawtooth is much shorter for queues 301 and 302 because they carry packets from n1p3 and n1p4 which are not delayed. On the other hand, the period of the sawtooth shape of the queue length of queue 300 is substantially larger than those of the other two flows (queue 301 and queue 302) which are not delayed. Comparing the period here with the one in the preceding Web page where the delay was 50 msec shows that the period has beeen almost cut in half.

Tutorial >> Router Plugins	TOC