[Winpcap-users] pcap_get_selectable_fd for WinPcap

Guy Harris guy at alum.mit.edu
Sun Apr 26 14:40:59 PDT 2009

On Apr 26, 2009, at 12:33 PM, Andreas Rieke wrote:

> on unix systems, the function pcap_get_selectable_fd is very useful  
> for
> event loops with the select function. Unfortunately,
> pcap_get_selectable_fd is not contained in the windows  
> implementation -
> at least not in WinPcap 4.0.2.
> Is it planned to implement the function in 4.1 or later versions? Or  
> is
> it already implemented? Or is it technically hard/impossible to
> implement that on windows systems?

As far as I know, the answer to the last question there is "yes".

In UN*X systems, file descriptors are the lowest-level entities use to  
refer to objects that can supply events (with the exception of window  
system events in Mac OS X/iPhone OS), and select() and/or poll() and/ 
or kqueues and/or epoll - all of which work with file descriptors -  
are the lowest-level APIs for implementing event loops.

In Windows, it's a little more complicated.  HANDLEs are the lowest- 
level entities used to refer to many objects that can supply events  
(not including window system events), and WaitForMultipleEvents() are  
the lowest-level APIs for implementing event loops.

*However*, Windows has a separate set of networking APIs that use  
SOCKETs rather than HANDLEs to refer to network connections - which  
are objects that can supply events - including a select() call similar  
to the UN*X select() call, except that it *only* works on sockets -  
and isn't

> Can I maybe - with some modifications
> - use the handle returned by pcap_fileno within the select loop?

No.  pcap_fileno(), on Windows, returns a HANDLE cast to DWORD, not a  
SOCKET - and, as far as I know, there's no way to turn a handle of  
some other sort into a SOCKET.

> I do know that windows has a similar function WaitForMultipleEvents,  
> but
> things are much easier when different versions of pcap are compatible;

> additionally, it makes no sense to use select for some events and
> WaitForMultipleEvents for some other events.

I agree.  Welcome to the wonderful world of Windows, wherein, even if  
you *don't* use WinPcap, you have to, as far as I know, use select()  
for some events (socket events) and WaitForMultipleEvents() for other  
events (and MsgWaitForMultipleEvents() if you also need to wait for  
window system events), unless there's some way to get a waitable  
HANDLE for a socket, in which case you could use  
WaitForMultipleEvents()/MsgWaitForMultipleEvents() for everything.  It  
appears that WSAAsyncSelect() lets you turn socket events into  
*window* events, but that doesn't help for programs that aren't GUI  

The only way you're going to be able to use the *same* code for an  
event loop would be if libpcap/WinPcap provided a function that took a  
set of pcap_t's as arguments and blocked waiting for a packet to  
arrive on one of them or for a timeout; on UN*X, it'd use select(),  
and, on Windows, it'd use WaitForMultipleEvents().  That wouldn't help  
if you want to wait on a mixture of pcap_t's and other event sources;  
as far as I know, *nothing* can help you there.

More information about the Winpcap-users mailing list