[Winpcap-users] Win32 gui programs

[Guy Harris]

On Feb 24, 2006, at 11:16 AM, Ramiro Polla wrote:

> What is the best method to listen on interfaces on win32?
> Using threads for pcap_loop? Using pcap_next_ex in the main message  
> loop?

...or use whatever the API is for getting the handle for arriving  
packets, and have the main message loop do MsgWaitForMultipleEvents()  
(if it doesn't do so already - I don't know how Windows message loops  
tend to be done on Windows) so that it waits for GUI messages *and*  
arriving packets and, when an event arrives on that handle, use  
pcap_dispatch() to process the packets that are available at the  
time.  (I'm not a Windows GUI programming expert - I'm not a UNIX+X  
GUI programming expert, either, but I know enough that a similar  
technique would be used there, by adding a selectable FD for the  
pcap_t to the main GUI loop.)

(I'd look up the name of the routine, but the links to the WinPcap  
documentation appear no longer to be in an obvious place on the  
WinPcap Web site.)

> I'm currently using pcap_next_ex in the main message loop, but on  
> heavy loaded networks, it takes a really long time for the packets  
> to get processed.

"Processed" in what sense?  Does your application do a lot of work on  
each packet?

> Also, do packets get dropped if they take too long to be processed?

Possibly - if packets arrive faster than the application using  
libpcap/WinPcap can consume them, when the buffer being used for  
packets fills up, packets will be discarded.

> I want to be able to process all packets as soon as possible,  
> without losing responsiveness in the gui.

You *might* want to do all time-consuming (especially CPU-time- 
consuming) packet processing in another thread, then - I presume  
that, on a single-processor machine, the thread with the main GUI  
message loop would probably end up running at a higher priority than  
the thread doing the CPU-time-consuming packet processing and, if  
it's blocked waiting for a message and one arrives, it will preempt  
the packet processing thread, and on a multiprocessor machine (a  
machine with one hyperthreaded processor is probably best thought of  
as a uniprocessor machine in this context, but a dual-core machine  
would be dual-processor) the two threads could run at the same time  
with no preemption required.