[Winpcap-users] Using threads.

[David Barnish]

Whether the read call blocks or not depends on the read timeout value
passed to the pcap_openxxx() function and the SetMinToCopy() value if
used. If the pcap_openxxx() function was told to return immediately (a
-1 is passed I believe for param 4), the pcap_dispatch() and
pcap_next_ex() will return immediately whether there are any packets to
read or not. The code that Ramiro included showed that a 1 millisecond
read timeout is used. So, within his while loop, the code will wait at
most 1 millisecond (give or take a few milliseconds) before it returns.
When it returns, it may have a packet of data, or it may return a null
packet pointer if there were no packets to read. So, I still say that he
is spinning in his while loop and taking away CPU resources from other
threads. In fact, the problem should be worse when there are no packets
arriving at the interface being sniffed. I may be wrong, but this is how
I am reading the WinPCap code.

An easy test for this assumption would be to use a larger read timeout
value in the pcap_open_live(). Instead of using 1 millisecond, use
something like 1,000. 


Thank you,
David Barnish
 
Senior Software Engineer R&D
Spanlink Communications


-----Original Message-----
From: winpcap-users-bounces at winpcap.org
[mailto:winpcap-users-bounces at winpcap.org] On Behalf Of Guy Harris
Sent: Wednesday, March 15, 2006 1:15 PM
To: winpcap-users at winpcap.org
Subject: Re: [Winpcap-users] Using threads.

David Barnish wrote:
> Just my opinion from quickly looking at the code, but I think your
> problem is thread contention/context switching.
> 
> For each thread, you have an endless loop that calls pcap_next_ex(),
> processes the packet, then immediately loops and does the same thing.
> Each thread will be trying to run non-stop and processing incoming
> packets until the OS forces it out of the CPU queue so another thread
> can run. This is similar to two threads running a function like this
at
> the same time:
> 
> While(true)
> {
> 	Printf("Hello World.\n");
> }
> 
> Both threads are trying to use system resources and are not giving up
> control voluntarily.
> 
> My suggestion is to use the pcap_dispatch() function (or something
> similar) so the thread will sleep for a bit, then wake up and process
> multiple packets.

The thread will only sleep in pcap_dispatch() if there are no packets 
available to be read at that instant.

The same is true for pcap_next_ex(); the only difference between a loop 
using pcap_dispatch() and a loop using pcap_loop_ex() is that the loop 
using pcap_dispatch() could process more than one packet per 
pcap_dispatch() call while the loop using pcap_loop_ex() processes only 
one packet per pcap_loop_ex() call.

"Processes" here means "hands to the callback" in the case of 
pcap_dispatch() and "returns to the caller" in the case of 
pcap_next_ex().  Both pcap_dispatch() and pcap_loop_ex() ultimately call

the read op for the pcap_t; in WinPcap, the read op:

	checks whether there are any packets left in its buffer and, if
there 
aren't, reads a new batch of packets into the buffer - that read might 
return immediately or might block;

	processes all the packets in the buffer if called with a count
argument 
of -1, or processes no more than the number of packets specified with a 
positive count argument.

pcap_next_ex() calls it with a count of 1; pcap_dispatch() calls it with

the count specified to pcap_dispatch().

So there won't be a difference between the two loops with regard to when

they sleep - they'll sleep if the kernel code blocks waiting for enough 
packets to arrive or for the timeout to expire.

The pcap_next_ex() loop makes more calls to the read op, as each call 
asks it to process only one packet from its buffer, so it might consume 
more CPU time; that's the only difference you should see.

> Another method would be to get the read event for the interface and
put
> a WaitForSingleObject() call at the top of the loop, waiting on this
> event and using a timeout of 500 milliseconds or so. In this way, the
> thread would voluntarily give up control for a short time

Not if there are packets ready to be read.
_______________________________________________
Winpcap-users mailing list
Winpcap-users at winpcap.org
https://www.winpcap.org/mailman/listinfo/winpcap-users