Glop

My work at the moment is building a Tor based simulation. I’m using the java SSFNet simulation tool which is designed to be extremely scalable. Hopefully I’ll be able to implement thousands of nodes, with hundreds of thousands of connections. At this stage I have a rudimentary implementation of the Tor protocol, with a torProxy, torRouter and torExitRouter. I can connect a testTcpClient to a testTcpServer via the torProxy, 3 torRouters and a torExitRouter.

It’s very simple, the tcpClient sends a request for some data and the tcpServer sends data of that size back. When the tcpClient recieves the data, it disconnects and the established torCircuit is torn down. (Well it should be. At the moment, everything just dies when the connection closes)

Obviously the most important part of the simulation for me is getting results from it. At the moment what I’m interested in is obtaining packeting timing information which will allow me to compare streams on one part of the network with streams on another part.

There is a measurement infrastructure in place in SSFNet, however I got a tad confused with the documentation for it. It’s actually extremely straightforward though. I thought I’d document what I’ve done so far. The SSFNet community in general is quite small, the tool doesn’t appear to be actively developed, so I figured any spur to this might help. It’s also handy for me for logging what I’ve done.

Utilising a BasicRecorder via a ProbeSession

In the DML file for your simulation, add the following to the graph section

ProtocolSession [
name probe use SSF.OS.ProbeSession
file "/tmp/mystream.dat"
stream "My Stream"
]

This will create a ProbeSession “pseudo-protocol” within the graph. This can then be accessed like below

if(this.recorder == null)
{
ProbeSession probe = (ProbeSession)this.owner.inGraph().SessionForName(”probe”);
this.recorder = (StreamInterface)probe.getRecorder();
}

Where this.owner is a class extending the ProtocolSession class. The StreamInterface returned is actually an object of type BasicRecorder, this isn’t mentioned anywhere in the documentation. I haven’t quite figured out how to get a different StreamInterface implementing class returned.

Once this recorder has been obtained, it can be written to quite easily using the send() method.

byte[] nothing = new byte[10] ;
String writer = owner.localNHI;
String type = VIRTUAL ;
int nWriter = this.recorder.getRecordSourceCode(writer);
int nType = this.recorder.getRecordTypeCode(type);
this.recorder.send(nType,nWriter, owner.localHost.now()/(double)SSF.Net.Net.seconds(1.0),nothing,0,10);

It took me a while to figure out where the BasicRecorder class was getting the int values from for the Code strings. It just creates internal numbers, ints, to store the string the first time it’s called and subsequently uses that int for every other call. Everything is figured out by looking at the code of course, luckily most of SSFNet is opensource.
To view the outputed log in /tmp/mystream.dat, you can use the BasicPlayer class. The stream identifier is as defined in the DML file, “My Stream”. with a 0 appended.

gavin@gavbot:~/workspace/ssfnet/bin$ java SSF.Util.Streams.BasicPlayer “My Stream.0″ /tmp/mystream.dat.0 > output.tmp
{Player processed 825 records, 8210 bytes, in 0.1 seconds (82 KB/s)}
gavin@gavbot:~/workspace/ssfnet/bin$ head -5 output.tmp
[type=3 ("Real") source=2 ("2") time=1.276107562 bytes=10]
[type=3 ("Real") source=4 ("3") time=1.278110762 bytes=10]
[type=3 ("Real") source=2 ("2") time=1.280161322 bytes=10]
[type=3 ("Real") source=4 ("3") time=1.286252842 bytes=10]
[type=3 ("Real") source=5 ("4") time=1.288256042 bytes=10]
gavin@gavbot:~/workspace/ssfnet/bin$

My next step is to hook the stream recording and playback up to the RaceWayViewer tool, so as I can actually see what’s going on in the network. It’s not particularly important, or remarkably useful, but it is handy to demonstrate how the simulation works. Beyond that lies creating larger networks, testing the simulation in comparison with the real tool and then starting to analyse results if the simulation output approximates the Tor output.

The morning time is my arch nemesis

I used TrekBuddy to record my cycle home this evening, spewing out NMEA data every second. GPSBabel can then convert this NMEA data into the slightly more common GPX XML format. I had planned on taking the data from the GPX file, using a shell script, then drawing graphs from it in Matlab. Being lazy though, I googled first for alternative solutions and came across the excellent uTrack website. This site allows you to upload a GPX file, and then creates graphs and statistics about your route. It also plots your route on a Google Map.

There are one or two drawbacks with it though. It’s not very easy to then display this data on ones website. There is an export to PDF option, but the graph quality is not as good as the original output and it also does not include the Google Map route tracking. The second problem seems to be with the script itself. It introduces spikes in the speed graph for some reason. Apparently I was cycling at 227km/h at one point. While this is certainly achievable for me on a flat stretch of road with my complete spandex outfit, and aerodynamic helmet, not to mention motorcycle, it’s not too feasible going through Dublin with its abundant traffic lights.

As a temporary solution, I have copied some of the graphs, and also have the original PDf available. Hopefully the author of the script will make it public or configure a nice way of including the HTML output on an external website.

Route PDF File

I looked at a way of preloading the j2memap application with maps from Google Maps. Great! I can put the maps on the phone, no permission errors, no messing. Or so I thought, unfortunately it’s actually quite crap.

I found an application that given a particular URI will download maps from that source for a given set of coordinates, longitude and latitude. You also choose the zoom level.

Now, I wanted a map of Dublin on my phone. For it to be of any use, it needs to have a reasonable level of zoom, which when downloaded with the above application spews out around 30 or so mb of map data. Grand job, no hassle, I’ve a 1GB memory card in the phone. Of course I was being somewhat stupid about it.

By preloading a jar file, as described here, you take the maps, convert them to a certain filename and stored them in the cache directory in the jar. A Java jar file being in fact a zip file, so this is quite easy. The problem occurs when you want to load this jar onto the phone. My phone, a SE K750i, copies the jar file to the phone memory before it runs… So I am going to be always limited to the phone memory size, not the size of the memory card. *NNNNnnnnnngggghhhh*

I am just going to have to wait for a signed midlet that loads the data from the memory card filesystem. I did also look at writing a small httpserver, which would have encountered the same problems as above, but in fact the phone can only run one java application at a time anyway !