Skip to content
Snippets Groups Projects

Add a tcp client & server standalone binary

Merged Victor Toso requested to merge victortoso/usbredir:usbredirect into master
1 unresolved thread

usbredir currently has usbredirserver that acts as TCP server for sharing local USB device with remote machines but it lacks a TCP client. Also, current usbredirserver does not build on windows and some changes in how it interacts with libusb would be needed to work on windows.

The goal of this MR is to have another binary that can act as TCP client/server and work on Windows and Linux. I'm using glib/gio to more easily handle different platforms. Perhaps we can have this binary to deprecate the existing usbredirserver and usbredirtestclient in the future.

My personal goal here is to give the possibility to projects to use usbredir without the need of implementing similar code. I have a proof of concept with KubeVirt PR/4089 using usbredirserver for now.

I'm calling this binary usbredirect and I've placed it in a new folder called tools.

Although I think this MR is ready for review, I would also like to add in near future some inter-process communication to give the possibility to the caller (like KubeVirt) to interact with usbredirect.

Comments and reviews are welcome ;)

Merge request reports

Loading
Loading

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
  • I have different opinions about this change. Although using Gio makes some things easier it also introduce a dependency just to make sockets more "portable", honestly I don't see much issues using just sockets and a very thin compatibility layer (like it was done for spice server, just couple of macros/small functions). Surely I won't introduce Gio on the lower level, on 98% of desktop (Windows and Mac) Gio is not a system library and would potentially complicate its usage; but you just used for an executable tool.

    I don't like the idea having 2 executables in the same project doing the same thing, I would plan to have just one.

    OT: At the beginning I though by client you did something like an executable running on any machine (even bare metal) that would connect to a server and expose the device, a bit what Qemu does here. In this case is just relaying the device but doing the connection instead of listening for a connection. Anyway, good too.

    You mentioned usage with external project but then yourself didn't use it but used the current executable. In my mind it's a bit contradictory.

    1. Indeed, my intention around introducing GIO is for the tool/usbredirect only. I'm not planning on rewritting usbredir library with support for it, etc. I really don't see an issue in usbredir (project) having a tool with an extra dependency (Gio). If this is merged, people can still use usbredir without usbredirect or adding gio dependency.

    2. I agree on not having two binaries doing the same thing. I would expect to remove server and the testing client binaries after some integration tests with usbredirect. It might take some time as people might use usbredirserver, so we need to deprecate it later.

    3. I didn't understand the contradiction of usbredirect? I would like to have the useful use cases of usbredir under a single binary. We can add more.. I'm interested in doing it :)

    And in regards to PR/4089 it is using usbredirect for a while now. I'll be rebasing it shortly after I figure out one of (unrealated to usbredir) API changes, probably this week.

  • Btw, many thanks for taking a look and reviewing. Do you feel that isn't interesting to usbredir to have a single tool like usbredirect?

    I'm also thinking that usbredirect will need some more dependencies related to authorization like polkit/dbus.. but again, I'd prefer to think about those things after getting something with the basics working for both linux and windows

  • Victor Toso mentioned in issue #1 (closed)

    mentioned in issue #1 (closed)

  • Victor Toso added 15 commits

    added 15 commits

    • 56ebd27b...cd52c3a5 - 4 commits from branch spice:master
    • cd219b7a - usbredirhost: handle return value from libusb_set_option()
    • b175be59 - usbredirhost: clamp the boundaries of log level
    • 62d541c6 - usbredirect: Introduce usbredir TCP client
    • c7c61706 - usbredirect: Introduce option to act as TCP server
    • 1f48dba4 - usbredirect: Add keepalive flag
    • d8bd34e0 - usbredirect: Add log verbosity control
    • 91cba244 - usbredirect: Handle libusb logs
    • adc630c4 - usbredirect: Accept bus-dev number for --device
    • 885381b3 - usbredirect: Add basic man page
    • b1d19879 - ci: add windows build
    • 0f0c61aa - ci: add check for tools

    Compare with previous version

  • I think that with this last version, it should be fine to deprecate usbredirserver and remove it after next release.

    If I could mock some usb device, it would be great to add this to CI too...

  • Victor Toso added 17 commits

    added 17 commits

    • 0f0c61aa...fa90781b - 8 commits from branch spice:master
    • c4c501a1 - usbredirect: Introduce usbredir TCP client
    • 306cc1d3 - usbredirect: Introduce option to act as TCP server
    • 09f89453 - usbredirect: Add keepalive flag
    • 404e242c - usbredirect: Add log verbosity control
    • d692569d - usbredirect: Handle libusb logs
    • 4ce9ba1e - usbredirect: Accept bus-dev number for --device
    • 6b0f6586 - usbredirect: Add basic man page
    • 946697e3 - ci: add windows build
    • 80513b91 - ci: add check for tools

    Compare with previous version

  • mentioned in issue #11 (closed)

  • mentioned in issue #12 (closed)

  • Victor Toso added 11 commits

    added 11 commits

    • 80513b91...195ddd7e - 2 commits from branch spice:master
    • 84efb7eb - usbredirect: Introduce usbredir TCP client
    • dfd1c28c - usbredirect: Introduce option to act as TCP server
    • 14df48e2 - usbredirect: Add keepalive flag
    • 905360df - usbredirect: Add log verbosity control
    • 2f30e68f - usbredirect: Handle libusb logs
    • c50dc42c - usbredirect: Accept bus-dev number for --device
    • b6c7f127 - usbredirect: Add basic man page
    • e251f9e8 - ci: add windows build
    • ab6dcab2 - ci: add check for tools

    Compare with previous version

  • If I could mock some usb device, it would be great to add this to CI too...

    It might be possible in the future with umockdev

    I think that with this last version, it should be fine to deprecate usbredirserver and remove it after next release.

    @freddy77 what do you think?

  • Julien Ropé
    • Resolved by Victor Toso

      Looks good to me.

      Agree to deprecate usbredirserver too - not sure on the timeline to do it, but we definitely don't want to keep two similar tools.

  • Victor Toso added 8 commits

    added 8 commits

    • cbd69b99 - usbredirect: Introduce option to act as TCP server
    • 12f1f0a7 - usbredirect: Add keepalive flag
    • f83e7434 - usbredirect: Add log verbosity control
    • 14793ceb - usbredirect: Handle libusb logs
    • 28389778 - usbredirect: Accept bus-dev number for --device
    • 8fa79f73 - usbredirect: Add basic man page
    • e0614f15 - ci: add windows build
    • 4d173689 - ci: add check for tools

    Compare with previous version

  • merged

  • Please register or sign in to reply
    Loading