Hi, I have been using the wpcap, but my problem is this;
As i explained earlier, i have to delay the packets f.ex. 40 milli seconds. My internal clock is updated (Windows 2000) every 15 ms at the present time. I tried increasing the update interval to 1 ms, but even though my user is administrator (And I checked all the local policy's), i get the error "Acces denied" when i try to retrieve or alter the process's security/access token. This prevents me from updating the interval between updates of the internal clock to 1 ms, and I haven't got time to go deeper into the security structure of Windows 2000, and haven't got any documentation on the subject. I don't want my application to run in a while(1) loop for obvious reasons, so if i'm not able to get the internal time with a higher resolution than 15 ms, my program can never be exact enough. I would have the header timestamp with us precision, and compare it to my internal time, which would have a presicion between 0-15 ms. This would be a problem. For that reason i've added my own little timestamp to each packet, that (because of the use of MIDI timers) has a resolution of 1 ms. This indicates the number of ms that must have passed from the program started, before the packet can be sent. Because this "timestamp" is added when the packet is retrieved from the npf drivers buffer. If I use wpcap, I risc having the packets to long in the wpcap buffer, before they get "stamped". This solution has given me a resolution of between 0-1 ms. I can live with this. (Even though it could be a bit more under higher network loads - I've implemented some things that should help this) You're new feature (PacketSendPackets()) makes it possible to make the resolution even higher, but also requires me to hand the packets to the wpcap before the actual time has come (I presume the presicion of 1-2 us, requires that the packet is already in the npf drivers buffer). I'm implementing a varying bandwith limitation, which requires me to "save up" enough bandwith before actually sending the packet. Since i have to save up bandwith, i can't be sure that the packet can be sent when the time comes anyway, and therefore i cannot hand it to the npf driver. Therefore i'm not sure if i want to try and accomplish a higher precision when I don't have alot of time left on the project. As I said the current solution meets the presicion demands for my program, so... This was a long story. Hope it maid just a little sence. Thanks for developing a great library, and for being there to answer (stupid? :o)) questions!!! - Jesper Munkholm -----Original Message----- From: Gianluca Varenni [mailto:[EMAIL PROTECTED]] Sent: 9. august 2002 16:01 To: [EMAIL PROTECTED] Subject: Re: [WinPcap-users] Changes to the Packet.dll and kernell driver Just a simple question: why don't you use the pcap API, instead of the Packet one? GV ----- Original Message ----- From: "Loris Degioanni" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, August 09, 2002 3:40 PM Subject: Re: [WinPcap-users] Changes to the Packet.dll and kernell driver > Hi, > > ----- Original Message ----- > From: "Jesper Munkholm Jensen (JMJ)" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Friday, August 09, 2002 1:16 PM > Subject: RE: [WinPcap-users] Changes to the Packet.dll and kernell driver > > > > Hi again, > > > > I meant where all the changes maid to the wpcap.dll, but i then continued > > browsing through the new documentation, and found my answers. > > But now i have a new one :o) > > > > The function PacketSendPackets() that can send a buffer of raw packets. It > > is written that it demands alot of processor power. I've been looking into > > the timing functions of 2000, and i believe I now how you acomplish this > > high resolution. > > But the function (KeQueryPerformanceCounter) which i'm thinking of > disables > > all (or some) interrupts when working, and for this reason Microsoft > doesn't > > recommend using it to measure accomplished time, or to call it frequently. > > Is this the one you use?? > > Yes. > AFAIK, KeQueryPerformanceCounter() doesn't disable interrupts. I suspect > Microsoft doesn't recommend using it because it's normally damn slow. > However, there is no other documented way to achieve microsecond precision > under WinNTx, unless using RDTSC, that however is often a real pain. > > > I'm developing a bridge, which among other things, introduces a delay to > all > > packets. One of my problems have been getting a reference from WinPcap, > > which could enable me to use the timestamp in the packet header when i > > calculate the time when the packet should be sent. Am I right in asumming > > that with version 3, i could retrieve a buffer of packets (With > > PacketGetPacket()), modify the timestamp of each packet in the buffer, to > > represent the time the individual packet should be sent, and then pass the > > buffer to the kernell driver with the PacketSendPackets() function? > > Yes, but take care that: > - if you work at packet.dll level, you will have to play a little with > headers, because the dump_bpf_hdr used by PacketSendPackets() is the one > passed to wpcap.dll applications, and is slightly different from the bpf_hdr > of PacketReceivePacket. > - the timestamps are considered to be relative, so PacketSendPackets() > always starts to send immediately > > Loris > > > I hope you can catch my drift as they say. I'm just a bit curious :o) > > > > - Jesper Munkholm > > > > -----Original Message----- > > From: Gianluca Varenni [mailto:[EMAIL PROTECTED]] > > Sent: 9. august 2002 12:21 > > To: [EMAIL PROTECTED] > > Subject: Re: [WinPcap-users] Changes to the Packet.dll and kernell > > driver > > > > > > > > ----- Original Message ----- > > From: "Jesper Munkholm Jensen (JMJ)" <[EMAIL PROTECTED]> > > To: "WinPcap Users List (E-mail)" <[EMAIL PROTECTED]> > > Sent: Friday, August 09, 2002 11:35 AM > > Subject: [WinPcap-users] Changes to the Packet.dll and kernell driver > > > > > > > Hi, > > > > > > A quick question. I browsed through the new WinPcap 3.0 documentation > last > > > night, but didn't browse it to the end. Does the new release contain any > > > significant changes to the Packet.dll and the kernel driver, or are all > > > changes maid to the WinPcap?? > > > > What do you mean? > > > > WinPcap is not only wpcap.dll, it is composed of wpcap.dll, packet.dll and > > the kernel driver. > > > > If you refer to wpcap.dll, yes, there are some new APIs, among which > > pcap_findalldevs, pcap_read_ex, pcap_livedump. > > > > GV > > > > > > > > - Jesper Munkholm > > > > > > > > > > >
