ok Guy - thanks for clarifying this for me

On 18 August 2010 12:12, Guy Harris <[email protected]> wrote:
>
> 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
>



-- 
Greg
http://blog.gregnet.org/
_______________________________________________
Winpcap-users mailing list
[email protected]
https://www.winpcap.org/mailman/listinfo/winpcap-users

Reply via email to