Ruby Wireshark Wrapper Status
I’ve not posted recently on the progress of my Ruby extension to wrap Wireshark’s packet dissectors and expose a complete protocol tree to Ruby.
I’ve finally reached a point where the initial groundwork is in place and I have a workable solution. I had severe performance problems, and ended up implementing a lookaside list to keep a cache of reusable C++ objects to avoid excess memory pressure, and also switched to use the Ruby memory allocator, which will trigger a GC if necessary to satisfy a memory request.
At this point I’m very pleased with the results. I can write a test app that looks for 802.11 management packets to build a list of wireless access points within a particular packet capture (all in Ruby), and process a libpcap-formatted capture file at a rate of 1500 packets/second, using a debug build of Wireshark and my Ruby extension. Keep in mind that rate includes building a complete protocol tree using Wireshark’s dissectors for each packet.
I can apply a display filter, set preferences, perform high-performance searches for specific field elements; everything I need to implement the network monitoring tool I’m working on.
All my code is in my SVN repository here, though I’ve not taken any pains to allow the code to build anywhere but my dev laptop so don’t expect to be able to get it working.
Also I haven’t taken the time to put in copyright notices yet, but the code is all Copyright (C) 2007 Adam J. Nelson, and the commies over at FSF require me to release it under the GPLv2, since that is the license under which Wireshark is released.
At this point I’m moving on to analyzing, storing, and displaying tens of gigabytes of network traffic using a Rails-based web interface and a SQLite back-end. I’m sure I’ll go back to rcapdissector to fix bugs, improve performance, add missing features, etc, but it’s no longer the primary focus.
I must say I find the Ruby extension experience to be harder than it has to be. I quickly abandoned mkext as it simply won’t work for a complex extension project, and found no suitable substitute. Docs were non-existent, and the lack of a good extension framework required me to come up with my own simplistic C++ idioms for representing extension objects. Then there’s the crappy performance I get out of Ruby 1.8 compared to what I’ve seen in Python.
Ruby’s a great little language, and I’m sure when it’s Python’s age it’ll really kick ass, but it still has a ways to go. And with the concurrent processing tasks I’m facing with this network monitoring tool, I’m tempted to bite the bullet and learn (gasp) Erlang. Ok, not really.
Note to self: new project idea. Design a new concurrent programming language that compiles down to Erlang. Goals of the language will be to use even more punctuation marks than Erlang itself, encourage the authoring of even less readable code, and introduce additional abstractions to increase the obfuscation level. Possible name idea: Hurlang.
Seriously though, WTF are the PragProg guys trying to push some sort of Erlang renaissance? I know, I know, thought-free concurrent programming and all that, but seriously. It was developed by telco guys who were so low on imaginative power that they named it after their company, Ericsson, hence ERlang. If you’re used to Ruby, or C#, or C++, or C, or fucking Javascript, it’ll be really hard to quiet your stomach when you read (and write) shit like this:
-module(test).
-export([fac/1]).
fac(0) -> 1;
fac(N) -> N * fac(N-1).
or this:
-module(tut9).
-export([test_if/2]).
test_if(A, B) ->
if
A == 5 ->
io:format("A = 5~n", []),
a_equals_5;
B == 6 ->
io:format("B = 6~n", []),
b_equals_6;
A == 2, B == 3 -> %i.e. A equals 2 and B equals 3
io:format("A == 2, B == 3~n", []),
a_equals_2_b_equals_3;
A == 1 ; B == 7 -> %i.e. A equals 1 or B equals 7
io:format("A == 1 ; B == 7~n", []),
a_equals_1_or_b_equals_7
end.
Tell me that doesn’t just make you want to cry! Hell, let’s just code everything in Lisp and get it over with. Ick. Pass.