4 ms·

The linked page says "High level != inefficient" and shows an example program which will print "every TCP packet". With no "if" anywhere in the code, I wondere

The linked page says "High level != inefficient" and shows an example program which will print "every TCP packet". With no "if" anywhere in the code, I wondered how it knew to print only TCP packets and not others. And the answer turns out to be that it throws a C++ exception on every non-TCP packet! If most of the packets on your network are TCP, this is sort of OK. But if you have mostly non-TCP packets, this toy program costs about 10x the CPU utilization that it would if it used "if" instead of magic.

_wmd 9y ago
There are plenty of ways they can keep the current API while eventually approaching optimal, for example, a chain of exceptions could incrementally refine the framework's idea of what the callback function expects, which could be turned into a BPF filter. So for the cost of a few expensive frames at start, afterwards no exceptions get thrown. Generally speaking though, I'm only replying because I hate people negging on minutia of new projects. If you're going to be critical of something especially when it's a lone wolf effort (or even a small team), try to be constructive, there are real people on the other end of the wire.
- tjoff 9y ago
  I thought the criticism was quite valid. If high efficiency wasn't touted as a feature then it would have been fine. But when it turns out that one of the main selling points is performance (with no expressed limitations or restrictions) and regular patterns perform badly, as a consequence of the design, then it is quite valid criticism. (Whether this is the case in practice I don't know but GP brings up a very valid point) GPs point begs the question - Why was it designed in such as way? Quite possibly the tradeoffs were considered and the current solution was targeted because of several reasons. But the page doesn't convey any of that, it simply states that "In fact, it is one of the fastest packet sniffing and interpretation libraries available.". While I agree with your point the library isn't exactly marketed as a lone wolf effort either, and that will also affect the criticism it will receive.
- jzwinck 9y ago
  A more charitable reading of my comment would be that I am recommending the use of "if" instead of C++ exceptions for hot-path control flow in high-performance libraries. Heuristic construction of a packet filter based on previously seen exceptions is infeasible with the current API because rejection of the first N non-TCP packets does not guarantee rejection of the next one.
  - to3m 9y ago
    There appears to be an alternative API that doesn't throw exceptions: https://github.com/mfontanini/libtins/blob/37c92fcf5c83b034a280fd6070fb467e3d0c87bd/include/tins/pdu.h#L75 https://github.com/mfontanini/libtins/blob/37c92fcf5c83b034a... (rfind_pdu uses it internally: https://github.com/mfontanini/libtins/blob/37c92fcf5c83b034a280fd6070fb467e3d0c87bd/include/tins/pdu.h#L369 https://github.com/mfontanini/libtins/blob/37c92fcf5c83b034a...)
garaetjjte 9y ago
Note that in SnifferConfiguration you can set pcap-style filters.
jcul 9y ago
It seems there is an rfind_pdu returning a reference and throwing if the PDU is not present, or a find_pdu returning a pointer which you can just test for null.
pea-tear 9y ago
Developer here. There's alternatives that don't throw but the example is mostly so people look at it and say "ah, cool, this is actually simple to use". I normally still use this throw-version of doing things when I just need to quickly do something, as in reality in most cases I don't care about performance for specific 10 line code snippets. If you want to do things right, you can read the docs and use the appropriate API call (like using the non throwing PDU::find_pdu, use bpf filters, etc).

_wmd 9y ago

There are plenty of ways they can keep the current API while eventually approaching optimal, for example, a chain of exceptions could incrementally refine the framework's idea of what the callback function expects, which could be turned into a BPF filter. So for the cost of a few expensive frames at start, afterwards no exceptions get thrown. Generally speaking though, I'm only replying because I hate people negging on minutia of new projects. If you're going to be critical of something especially when it's a lone wolf effort (or even a small team), try to be constructive, there are real people on the other end of the wire.

tjoff 9y ago
I thought the criticism was quite valid. If high efficiency wasn't touted as a feature then it would have been fine. But when it turns out that one of the main selling points is performance (with no expressed limitations or restrictions) and regular patterns perform badly, as a consequence of the design, then it is quite valid criticism. (Whether this is the case in practice I don't know but GP brings up a very valid point) GPs point begs the question - Why was it designed in such as way? Quite possibly the tradeoffs were considered and the current solution was targeted because of several reasons. But the page doesn't convey any of that, it simply states that "In fact, it is one of the fastest packet sniffing and interpretation libraries available.". While I agree with your point the library isn't exactly marketed as a lone wolf effort either, and that will also affect the criticism it will receive.
jzwinck 9y ago
A more charitable reading of my comment would be that I am recommending the use of "if" instead of C++ exceptions for hot-path control flow in high-performance libraries. Heuristic construction of a packet filter based on previously seen exceptions is infeasible with the current API because rejection of the first N non-TCP packets does not guarantee rejection of the next one.
- to3m 9y ago
  There appears to be an alternative API that doesn't throw exceptions: https://github.com/mfontanini/libtins/blob/37c92fcf5c83b034a280fd6070fb467e3d0c87bd/include/tins/pdu.h#L75 https://github.com/mfontanini/libtins/blob/37c92fcf5c83b034a... (rfind_pdu uses it internally: https://github.com/mfontanini/libtins/blob/37c92fcf5c83b034a280fd6070fb467e3d0c87bd/include/tins/pdu.h#L369 https://github.com/mfontanini/libtins/blob/37c92fcf5c83b034a...)

garaetjjte 9y ago

Note that in SnifferConfiguration you can set pcap-style filters.

jcul 9y ago

It seems there is an rfind_pdu returning a reference and throwing if the PDU is not present, or a find_pdu returning a pointer which you can just test for null.

pea-tear 9y ago

Developer here. There's alternatives that don't throw but the example is mostly so people look at it and say "ah, cool, this is actually simple to use". I normally still use this throw-version of doing things when I just need to quickly do something, as in reality in most cases I don't care about performance for specific 10 line code snippets. If you want to do things right, you can read the docs and use the appropriate API call (like using the non throwing PDU::find_pdu, use bpf filters, etc).