On Aug 17, 2010, at 7:00 PM, Greg Hauptmann wrote:
> Any advice/guidance regarding pro's/con's for the following options:
>
> a) minimise amount of packet matches by having a capture filter which
> has several "or" in it. Let say a filter that is something like
> "LocalHost and (ip 1 or ip 2 or ip3...ip10)", so say one "or" and 9
> "and"s.
>
> b) simple capture filter, and then programmatically filter in code for
> all the matches (e.g. packet filter might include the localhost only
> filter, but not then try to filter out the 10 ip's)
>
> I'm guess that option (a) should be the more optimal way to go,
That is almost certainly the case.
In both cases, you'll be filtering for all the IP addresses. The filtering in
the capture filter will be done by executing BPF pseudo-machine code or
on-the-fly compiled code that compares IP addresses in the packet against the
specified IP addresses. If you're doing this on a platform where the BPF
pseudo-machine code is interpreted, that will be less efficient than doing it
in compiled machine code in the program, but probably not by a lot; if you're
doing this on a platform where the BPF pseudo-machine code is translated into
real machine code and executed, it will probably be about as efficient.
At least for 32-bit x86, sufficiently recent versions of WinPcap will, I think,
translate it into real machine code and execute it (as will sufficiently-recent
versions of FreeBSD, which picked up the translator from WinPcap); FreeBSD also
wrote a 64-bit x86 (amd64/x86-64/x64/whatever you want to call it) version of
the translator - I don't know offhand whether WinPcap picked that up or not.
A packet that doesn't match the WinPcap filter will be discarded by WinPcap
before it's copied into WinPcap's kernel buffer, and thus also won't be copied
into the userland buffer when the WinPcap library reads from that buffer; all
other packets will be copied into WinPcap's kernel buffer, and then into the
userland buffer. The more packets that are copied into WinPcap's buffers, the
more CPU time is spent copying those packets, *and* the faster WinPcap's kernel
buffer fills up, and hence the faster it has to be emptied by the application
calling the WinPcap library routines to read packets in order not to have the
buffer get completely full before the next packet arrives - if the buffer is
full when a packet arrives, the packet that arrives is discarded.
That means that a filter that discards more packets
1) reduces the CPU requirement overall, even though it might take more
CPU to execute the additional filter instructions
and
2) reduces the chances that you'll drop packets.
_______________________________________________
Winpcap-users mailing list
[email protected]
https://www.winpcap.org/mailman/listinfo/winpcap-users
