rust-zmq VS InputShareUSB

It depends how useful you think the patch is, and maybe also how likely you think it will get merged.

In most cases I simply keep my fork as a PR and use the package either by vendoring or directly from the repo. If anyone else encounters the same bug, they will see my PR referencing the issue, they can do the same.

If many people are encountering the bug and using the package, and/or if the project seems dead, then it's a good idea to publish. You can do username prefix or you can just add "2" at the end. I've seen this for other repos, This is what https://crates.io/crates/zmq2 did while https://crates.io/crates/zmq was inactive, though it seems like the latter's maintainer became active and merged what the former's maintainer had done.

I have been using https://crates.io/crates/zmq since 2015 (shortly after rust 1.0 was announced) in production with pub-sub, request-reply and router without any issue. Processes about 5k msg/seconds (mid-freq market data).

I learned a lot about sockets with the library ZeroMQ, although at that time I was using the Python version. This library also has a Rust library, although it doesn't look like the amazing guide about sockets allows you to select Rust as of yet. Still I would recommend going through this guide, as it is not just teaching you how to use a library, but also teaches you about sockets at a theoretical level. It's entertaining to read as well.

I think maybe the ZeroMQ rust crate as a case study is something that is non-trivial: https://github.com/erickt/rust-zmq

Have you tried using a different cable? A few months ago I wrote a similar program and someone experienced the same issue and it turned out to be the cable.

I wrote something similar (windows --network--> raspi zero w --usb--> target device). My first attempt used a simple tcp stream without nagle's algorithm and it was completely useable because I was sending way to many packets this way. After turning nagle's algorithm back on it generally usable but it also introduced something like a 0.5s delay (it's easily noticable, trust me). However the whole thing was pretty unstable, because even a small hick-up in network quality would result in a death spiral that took around 2-3s to resolve itself and make the program usable again. I'm sure I could've optimized my naive tcp protocol further to make it more stable but I chose to fix the problem on the source and wrote my own simple, reliable, ordered network protocol on top of UDP. While it currently has some limitations (no encryption, no congestion control, connection loss is somewhat ungraceful) it runs amazingly stable even under bad network conditions and with unnoticeable latency.

Both the Windows and Raspberry Pi parts of this project are written in Rust and can be found here.

Yes. When you use the Linux gadget driver it creates a device like /dev/hid0 for you in that you can write your usb-hid packets. This means that you can write a simple script that listens to a TCP connection and simply forwards everything it receives into /dev/hid0. On the PC side of things you then simply connect to this TCP server and you're good to go. Here is an example of what I'm talking about.