Archive for the 'General' Category

TCP is the protocol that gets the most attention, and that makes some sense as it’s the one that carries your email and web pages, the two most popular applications on the net.   There are times, though, when TCP is not appropriate, like when you want to multicast data to several machines at once.

Multicasting takes advantage of the fact that LANs, such as Ethernet, are broadcast media, in which all hosts can, if they choose, see all the packets as they go by.

In order to use multicast you have to use a datagram protocol, such as UDP, for reasons that I will not get into in this posting.

One of the more important qualities to test for when building a multicast network is latency. Many people know about testing for bandwidth, i.e. how many bytes/bits per second can we shove down this pipe, but latency tests are rarer. Since such tests are rare I have written one which is now included in FreeBSD. It can be found in the src/tools/tools/mctest directory of CURRENT (8.0). An example is shown below:


Source
mctest -i em0 -s 1024 -n 100 -t 1
Sink
mctest -i em0 -s 1024 -n 100 -r

Send 100 packets of 1024 bytes, with an inter-packet gap of 1 nanosecond.

The mctest program includes both the source and the sink code, and the -r command line argument is what tells the program to be a sink (i.e. to receive packets).

The way that mctest tests for latency is that the source sends out a multicast packet and then the sink(s) send the packet right back. The sinks report statistics like the size of the gap between packets, which shows network jitter, and if any packets were lost. The source reports if packets were lost as well as the round trip latency of the packets.

Results from the test look like this on the source:

Results from client #0
sec: 0 usecs: 73
sec: 0 usecs: 44
sec: 0 usecs: 48
sec: 0 usecs: 39

which shows partial results. The results for all clients are actually output. There is also a convenient shell script mctest_run.sh which can be used to start sinks on multiple hosts. All of this is documented in the manual page as well.

Happy Testing!

In order to facilitate the debugging of networking code I have used my library, <a href=http://pcs.sf.net>Packet Construction Set aka PCS</a> to write a program I call the <a href=http://pktdbg.sf.net>Packet Debugger (pdb)</a>. All of this is written in Python and available under a BSD license. The blurb from the pdb web page gives you the best idea of what I’m doing:

“The Packet Debugger (pdb) is a program which allows people to work with packet streams as if they were working with a source code debugger. Users can list, inspect, modify, and retransmit any packet from captured files as well as work with live packet capture.” – pdb web page

There is a twelve page manual on the web page that describes how to use the debugger as well.

 As some of you may, or may not know, I tend to do a lot of my kernel development in virtual machines, such as <a href=www.vmware.com>VMware</a> and now <a href=http://www.parallels.com/>Parallels</a> on my MacBook. I find that virtual machines make the perfect test lab because you can easily create, copy, store, backup and delete them. For a more full discussion of using virtual machines for kernel and protocol development see my presentat from the <a href=http://www.bsdcan.org/2006/papers/VirtualProtocolandKernelDev.pdf>BSDCan</a> conference in 2006.

To build a proper network test lab you not only need machines with multiple interfaces but a way to hook those interfaces to each other. Until the most recent versions of Parallels, around December of 2006, this was not possible, and so I had to stick with VMware, on Linux. Now with the advent of 3 types of networking on Parallels, bridged, shared and host only, it is possible to have 3 interfaces independently active for use in testing.

At home my typical setup is that ed0 is a bridged network, which connects to the outside world, and ed1 is shared, and then ed2 is host only. Testing occurs on ed1 and ed2 in order for there to be a “quiet” network on which to do tests.

The next step that Parallels needs to take to make this truly work is to provide the equivalent of a hub per network, much like private networks in VMware, at which point all this messing about with different types of network interfaces can cease and I can safely continue to do testing wherever I like.

For those of you who want to do this kind of work I will be uploading my kernel configuration and other files in another post.