|
pileofrogs has asked for the wisdom of the Perl Monks concerning the following question:
I'm thinking about doing a little packet sniffing, so I poked my head into the CPAN search and found several modules that say they do lib pcap or other sniffy type stuff.
Net::Pcap seems like the obvious choice, but there's also Net::Packet::Dump, Net::Connection::Sniffer and others.
My specific question is, what module do you recommend to sniff outbound email headers from a bridged firewall.
My general, and I think more important question is, when confronted with several seemlingly similer modules like this, how do you pick the one to use? 2006-09-29 Retitled by planetscape, as per Monastery guidelines ( keep:5 edit:9 reap:0 )
Original title: 'How do you choose modules?' |
Re: Which packet sniffing module should I choose?
by andyford (Curate) on Sep 28, 2006 at 22:00 UTC
|
Good documentation and examples therein is a big draw for me.
I would not base my decision on whether there have been recent releases: many very useful modules have been stable and not updated for years.
| [reply] |
Re: Which packet sniffing module should I choose?
by sgifford (Prior) on Sep 29, 2006 at 03:03 UTC
|
I implemented something that sounds very similar with Net::Pcap and NetPacket.
In general, I read the documentation available on CPAN for the modules, see which one seems to come closest to what I want, then try it and see if it actually works. I'll also poke around inside the code a bit to see if I can extend it and fix bugs if I need to. If I'm not happy with the first one, I'll try the next. Choosing the right modules to build your code on top of is a really important decision, and you should expect to spend a moderate amount of time researching and testing.
| [reply] |
Re: Which packet sniffing module should I choose?
by Tanktalus (Canon) on Sep 29, 2006 at 02:16 UTC
|
The one time I can think of where I really had to research a bunch of modules to find something I wanted to use in production was finding something to use with XML. I downloaded and tested a whole bunch of modules. I poured over their documentation. I tried using each one in a scaled down prototype of what I would eventually try to do with them. And then I decided.
My basis was everything. How easy was it to use or learn. How complete it was feature-wise (YAGNI-be-damned, I didn't want to wait until I needed it before asking the module author to implement it). How useful it would be in not just this program, but other programs in the same field (learn one technology, reuse that learning in many places). And, how perlish it was. Some of the modules were thin wrappers around underlying C code with the barest of syntactical sugar to at least make it conform to perl (converting char*'s and int's to plain scalars, for example). Others not only believed in TIMTOWTDI, but were, by themselves, MTOWTDI.
I obviously picked XML::Twig. Which of yours you should pick? I don't know. But maybe the above will help you figure out how to pick one.
| [reply] |
|
|
I went through much the same exercise a year or so ago, and also picked XML::Twig. But I spent a lot of time on the research, there was no obvious place to go to find out even what was most popular, let alone what was the 'best'.
Why do you say you 'obviously' picked XML::Twig?
More recently, I had to do some XML stuff and this time picked XML::Smart, which suited the particular task better. But again I had to do my own research.
| [reply] |
|
|
If you read my basis for selection, you'll notice that one of the basis was having a single solution be MTOWTDI. XML::Twig is the only module that I know of that has more than one approach to XML. You can deal with each twig during processing (before or after or both) - great for transformations. Or you can load the whole thing into memory and use xpath-like expressions to find your data. I usually do the latter, though I've used the former from time to time.
It appears, from a very cursory glance, that XML::Smart is not necessarily a lot different from XML::Simple. XML::Smart may be able to handle more cases, and seems to have more syntactical sugar, but it, too, seems to take XML and simplify it down to common perl structures. Which means it can be great for things like serialising data for your own use. But may not be so great for fulfilling certain DTDs.
XML::Twig seems to have two very important features that make it the only choice for me. In order of priority for me and my use (which may not apply to you in your situation, that's why there really are many ways to do things), they are: a) XML::Twig keeps everything in its original context. This can be important in fulfilling those DTDs. What this means is that if I have two pieces of XML such as:
<foo>
<bar>blah</bar>
</foo>
and
<foo bar="blah" />
that XML::Twig handles these differently. However, XML::Simple does not. (You can choose the output of XML::Simple to be one or the other, but I'm not sure how to get it to do both - and to do that depending on the original input.) I suspect that XML::Smart does not do this either.
And, b) of the modules that do (a), it does so in the simplest, most perlish way. The modules that do (a) are generally the low-level ones that wrap around the DOM or whatever parsing mechanism they use at a very direct level. By no means is XML::Twig "simple" - but of this group, it is easily the winner.
Does that mean it's always the best module to use? Not necessarily. But it has been for me. | [reply]
[d/l]
[select] |
Re: Which packet sniffing module should I choose?
by kwaping (Priest) on Sep 28, 2006 at 22:32 UTC
|
| [reply] |
Re: Which packet sniffing module should I choose?
by GrandFather (Saint) on Sep 28, 2006 at 23:58 UTC
|
Search CPAN then, having either found a hundred modules which don't quite do the job I want, or having found none at all, Super Search. If that doesn't work ask in the CB.If that doesn't work post a SoPW it. :)
If that doesn't work,
DWIM is Perl's answer to Gödel
| [reply] |
Re: Which packet sniffing module should I choose?
by eXile (Priest) on Sep 29, 2006 at 15:21 UTC
|
| [reply] |
|
|
