In the first part of our blog series, we introduced our brand-new python module for scamper, the packet-prober underpinning much of Ark’s ongoing measurements. One aspect that we highlighted was the ability for potential users of Ark to develop their code locally, before running it on the Ark platform. When I develop measurement applications, I use a couple of local Raspberry Pis and my own workstation to get the code correct, and then copy the code to the CAIDA system to run the experiment using available Ark vantage points. The goal of this blog article is to describe different ways to locally develop your measurement experiment code.
Example #1: Starting small with one scamper process.
The easiest way to begin is with one scamper process running on the same system where you develop your python code. With scamper installed (we recommend that you use a package listed on the scamper website), start a scamper process, and make it available for measurement commands on a Unix domain socket. For example, you might run scamper as follows:
$ scamper -U /tmp/scamper -p 100
This will create a Unix domain socket to drive scamper at /tmp/scamper, and tell scamper that it can probe at up to 100 packets/second. You can adjust these parameters to what is appropriate locally.
You can then develop and debug your measurement code in Python. To use this scamper process, your Python code might begin as follows:
01 from scamper import ScamperCtrl
02
03 # use the scamper process available at /tmp/scamper
04 ctrl = ScamperCtrl(unix="/tmp/scamper")
05
06 # do a simple ping to 8.8.8.8 and print the outcome
07 o = ctrl.do_ping("8.8.8.8")
08 if o.min_rtt is not None:
09 print(f"{o.min_rtt.total_seconds()*1000):.1f} ms")
10 else:
11 print("no reply")
Example #2: Coordinating measurements among VPs.
Once you are comfortable using the python module with a single local scamper instance, you might want to test your code with multiple scamper instances, each representing a distinct vantage point. The scamper software includes the sc_remoted interface to support that. sc_remoted has features for authenticating endpoints with TLS, but you might choose to initially operate endpoints without the complexity of TLS.
sc_remoted listens on a port for inbound scamper connections, and makes Unix domain sockets — one for each VP — available in a nominated directory. The best idea is to create an empty directory for these sockets. You might run sc_remoted as follows:
$ mkdir -p /path/to/remote-sockets
$ sc_remoted -U /path/to/remote-sockets -P 50265
The first command creates the directory, because sc_remoted will not create that directory for you. The second command starts sc_remoted listening on port 50265 for incoming scamper connections, and will place Unix domain sockets in /path/to/remote-sockets as they arrive. Note, we use /path/to as a placeholder to the actual path in your local file system that is appropriate for your environment; you might put these sockets in a directory somewhere in your home directory, for example.
Then, on the systems that you want to act as vantage points, the following command:
$ scamper -p 100 -R 192.0.2.28:50265 -M foo.bar
will (1) start a scamper process, (2) tell it that it can probe at up to 100 packets-per-second, (3) connect it to the specified IP address and port to receive measurement commands from, and (4) tell it to identify itself as “foo.bar” to the remote controller. If you go into /path/to/remote-sockets, you might see the following:
$ cd /path/to/remote-sockets
$ ls -l
total 0
srwx------ 1 mjl mjl 0 Jan 22 16:57 foo.bar-192.0.2.120:12369
This socket represents the scamper process you just started. The filename begins with foo.bar, the parameter that you gave to scamper to identify itself. After the dash is the IP address and port number that the remote controller observed the remote system coming from. You can connect as many additional scamper instances as you like, and you will see them listed in the directory individually. You should name each differently with something meaningful to you (foo.bar, bar.baz, etc) so that you can identify them on the system on which you’re writing your python code.
The python code we wrote in Example #1 above might be modified as follows:
01 import sys
02 from scamper import ScamperCtrl
03
04 if len(sys.argv) != 2:
05 print("specify path to unix domain socket")
06 sys.exit(-1)
07
08 # use the remote scamper process available at the specified location
09 ctrl = ScamperCtrl(remote=sys.argv[1])
10
11 # do a simple ping to 8.8.8.8 and print the outcome
12 o = ctrl.do_ping("8.8.8.8")
13 if o.min_rtt is not None:
14 print(f"{o.min_rtt.total_seconds()*1000):.1f} ms")
15 else:
16 print("no reply")
And run as:
$ python ping.py /path/to/remote-sockets/foo.bar-192.0.2.120\:12369
If you have multiple remote-sockets in the directory, you can add them individually, or use all sockets in the directory. For example:
01 import sys
02 from datetime import timedelta
03 from scamper import ScamperCtrl
04
05 if len(sys.argv) != 3:
06 print("usage: single-radius.py $dir $ip")
07 sys.exit(-1)
08
09 ctrl = ScamperCtrl(remote_dir=sys.argv[1])
10 for i in ctrl.instances():
11 ctrl.do_ping(sys.argv[2], inst=i)
12
13 min_rtt = None
14 min_vp = None
15 for o in ctrl.responses(timeout=timedelta(seconds=10)):
16 if o.min_rtt is not None and (min_rtt is None or min_rtt > o.min_rtt):
17 min_rtt = o.min_rtt
18 min_vp = o.inst
19
20 if min_rtt is not None:
21 print(f"{min_vp.name} {(min_rtt.total_seconds()*1000):.1f} ms")
22 else:
23 print(f"no responses for {sys.argv[2]}")
and run this command:
$ python single-radius.py /path/to/remote-sockets 8.8.8.8
We encourage you to reach out via email if you have questions about using the module. In the first instance, you can email ark-info at caida.org.
