[Winpcap-users] Win32 gui programs

[Gianluca Varenni]

----- Original Message ----- 
From: "Guy Harris" <guy at alum.mit.edu>
To: <winpcap-users at winpcap.org>
Sent: Friday, February 24, 2006 1:58 PM
Subject: Re: [Winpcap-users] Win32 gui programs


>
> 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.)

Uhm, I wouldn't probably use this technique. The main problem is that 
whenever MsgWaitFor....() returns telling that some packets are available, 
how do you know when to call MsgWaitFor... and process WM messages, instead? 
You will end up having problems balancing the processing of packets vs. WM 
message processing. I would probably go with a worker thread receiving and 
processing packets, notifying the UI thread of updates with a custom inter 
thread WM message.

>
> (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.)

Guy, I think you don't like too much the new layout of the WinPcap web-site, 
right? ;-)

 We tried to make it more coherent, putting the online documentation in the 
developer's page (http://www.winpcap.org/devel.htm), but maybe the fact that 
the links to the online docs are quite down in that page do not make it too 
obvious to find...



>
>> 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?

In any case, it's usually quite risky to put such any processing code (and I 
consider a call to pcap_next_ex() as processing, as well): as explained 
before it's not trivial to balance the queue of WM messages with the queue 
of incoming packets on the same thread...

Have a nice day
GV

>
>> 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.
> _______________________________________________
> Winpcap-users mailing list
> Winpcap-users at winpcap.org
> https://www.winpcap.org/mailman/listinfo/winpcap-users
>