[prev in list] [next in list] [prev in thread] [next in thread] 

List:       libusb-devel
Subject:    Re: [libusb] What about a new Backend with USBIP - support?
From:       Jörg_Schubert via libusb-devel <libusb-devel () lists ! sourceforge ! 
Date:       2024-03-19 21:14:26
Message-ID: 7eb746b2-fa62-46df-8e55-f82c1c009446 () gmx ! net
[Download RAW message or body]

I think  there is no timing problem when using bulk transfers. But tcp/ip
latency and bandwidth may break isochronous mode.

In case of libusb, the client-side translation layer is easy. I don't have do
merge all devices into one kernel space. Every remote host will get it's own
libusb context. Looking at some use cases, I think this is a good choice:

1. The simple one: A single applications uses just one device. For remoting
there is nearly nothing to do. Just add an option to libusb_init_context() or
set ip address in environment.
2. The extreme one: Someone wants to connect a thousand remote device-trees 
(For what? Maybe an automatic usb-gadget testing station :-) ). There should be
no problem managing a thousand contexts. And the clean separation of connections
might be an advantage in that case.

Am 18.03.24 um 21:14 schrieb Tim Roberts:
> Jörg Schubert via libusb-devel wrote:
>>
>> BTW: The asynchonous internal nature of libusb fits perfectly to networking. USB
>> IS networking - dont't You think so?
>
> Yes, absolutely.  It's a star-topology protocol-based network. What makes it
> tricky is the strict timing requirements.  Latency is the big killer is
> spanning USB across a network.  Certain requests require sub-millisecond
> responses.
>
> The typical USB-over-IP solution tries to be general case.  The server side
> has a USB-to-IP translation layer, and the client side does the opposite,
> pretending to be a USB hub and attempting to fool the operating system into
> loading standard drivers.  That's very tricky.  What you're proposing
> essentially eliminates that client-side layer -- you don't need a driver, and
> you don't need to pretend it's USB.  You know it's coming over IP.  It's not
> as general, but it should be do-able.
>
>
>
> _______________________________________________
> libusb-devel mailing list
> libusb-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/libusb-devel




_______________________________________________
libusb-devel mailing list
libusb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[prev in list] [next in list] [prev in thread] [next in thread]