Gianluca Varenni wrote: > There is always a wait, but it's performed in user mode > (and not in the driver). So the driver doesn't need the > timeout. > > This is what happens: > 1. packet.dll creates an unnamed event and passes the HANDLE > to the driver
You forgot CreateFile. The HANDLE returned by CreateFile is what is used in that BIOCSETEVENTHANDLE call. The BIOCSETEVENTHANDLE call associates an event handle with a given open instance. It essentially associates a CreateEvent HANDLE with a given CreateFile HANDLE. > 2. the driver is responsible for setting/resetting the event > when packets are available or not Yes. > 3. inside PacketReceivePacket, there is a WaitForSingleObject > on that HANDLE (with a timeout) Correct. Each open instance has its own event handle it can wait on. As long as each WinPCap "user" only uses their own handle (as returned by CreateFile), then none of them can interfere with each other. That is what PacketOpenAdapter, PacketSetReadEvt (done by PacketOpenAdapter) and PacketReceivePacket is designed to control. But if I more or less do the exact same thing myself, then there is no way for me to interfere with anyone else. The point I was simply trying to make is simply the following: 1. BIOCSRTIMEOUT is still supported. 2. If it goes away, then BIOCSETEVENTHANDLE should be used. 3. calling the low level ioctls is NOT more risky or dangerous that using the Packet APIs since the Packet APIs themselves are (since they're doing the same thing). Some people like using "fopen" and "fread", etc (i.e. using the CRT to access their files). I prefer using CreateFile and ReadFile. Doing CreateFile and ReadFile is not more "dangerous" than using the CRT's "fopen" and "fread", since ultimately that's what fopen and fread does. Understanding how the low level i/o works and having the option of using it is important to some of us, and blanketly stating that using anything other than the "Packet" APIs is wrong in my opinion. It is NOT wrong to bypass the Packet APIs and do the low level yourself. As long as you fully understand the repercussions of your doing so. Which is NOT very clearly documents unfortunately. And THAT, more than anything, is what is ultimate wrong. Thanks for listening. -- "Fish" (David B. Trout) [email protected] _______________________________________________ Winpcap-users mailing list [email protected] https://www.winpcap.org/mailman/listinfo/winpcap-users
