Utilising stream recording in SSFNet
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.
Powered by FireStats