I'm in the middle of implementing a userspace client for usbip and I
strongly feel that the protocol needs to be changed before it is merged.
- I'm unconvinced that TCP is the correct protocol to be running this over.
I understand the reluctance to use UDP, but the protocol is fundamentally
packet-based. If TCP is used, the delimitation of packets within the
stream needs to be much more robust. I've managed to wedge the VHCI driver
a number of times in ways that just wouldn't be possible if we were using
a packet protocol instead of a stream protocol.
- Endianness. This is a mess. The usbip protocol is big-endian, but the
encapsulated usb protocol is little-endian. This doesn't matter to the
people who are just tunnelling usb from one computer to another, but for
someone implementing a usbip client, it's very confusing.
- The protocol needs an officially assigned port number. Port 3240 is
already assigned to Tony Matthews <tmatthews&triomotion.com> February
2002 (see http://www.iana.org/assignments/port-numbers)
- There are actually two completely different protocols in use. First,
the usbipd daemon listens on port 3240, and handles device discovery.
When usbip successfully attaches to usbipd, both sides of the connection
pass the socket fd into the kernel and the protocol changes.
- The protocol sends a 48-byte packet header for every command (and every
response). It's cunningly hidden as a union.
I think the protocol would be immeasurably improved by going through the
IETF RFC process and getting feedback from networking experts. Failing
that, I have some suggestions about how to improve it. I was hoping to
get my client finished before I started mucking with the protocol though.
(I have some other comments on the implementation, but they're a separate
issue).
--
Matthew Wilcox Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
--
