Sendqueue

[qrnch-jan]

Implement support for sendqueue, which is a feature available in winpcap/npcap that allows Windows applications to send raw packets at a high sustained rate.

[Stargateur]

I forget to add this require some tests.

And also you forget update CHANGELOG

Overall, this doesn't look very user-friendly. Need to call reset() "at hand", no much configuration.

[qrnch-jan]

The original sendqueue API is very .. spartan.

It doesn't have any reset at all, and the transmit function doesn't automatically reset. Apparently if the transmit fails, the len is used to keep track of what packet failed. So calling transmit again will retry from that point. To reset one can manually set the len to 0. (Which is what the crate's reset() does).

Also, I learned that the alloc/release functions don't actually allocate any magic buffer -- we could allocate any regular "Rust" buffer instead. I used the sendqueue API's in case that changes in the future. However, npcap's developer was quite clear about that it is safe to completely manage the buffer oneself.

Anywho; I'll work on the remaining points, and with regards to user-friendlieness -- I can make the transmit auto-reset on success. Were there any other changes you had in mind?

[qrnch-jan]

I forget to add this require some tests.

I'm having some trouble with this, because there's no obvious target to send packets to.

These updates are being developed for an application which has both a sender and receiver end, but this is not easily transformed to an isolated test case.

[Wojtek242]

Can you please fix the clippy issues, and address the one comment I left?

At present it is difficult to add tests as there is no good testing framework for it, so please add an example instead which a user can run on their machine to verify it works.

Otherwise, since you've already addressed @Stargateur's comments it looks ready to merge.

[qrnch-jan]

I've added an example which manually builds raw ethernet packets, queues them up and transmits them. It uses a non-standard ethertype to avoid clashing with existing standard protocols. One could argue that this could interfere with non-standard ethernet devices using ethertype 0x5555, but I figure that anyone looking to send raw ethernet packets is well aware of what this means.

The upside is that one can run a packet capture tool and filter on ethertype=0x5555 on the receiving system to easily see the transmitted packets, without getting noise from regular traffic.

I could make the ethertype configurable, but going by the other examples it looks like the examples are meant to be to-the-point (i.e. act as reference code).