From: Matthew Wilcox <matthew@wil.cx>
To: Greg KH <greg@kroah.com>,
bgmerrell@novell.com, hirofuchi@users.sourceforge.net
Cc: linux-kernel@vger.kernel.org, usbip-devel@lists.sourceforge.net
Subject: USBIP protocol
Date: Fri, 29 Aug 2008 08:02:24 -0600 [thread overview]
Message-ID: <20080829140224.GC1968@parisc-linux.org> (raw)
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."
next reply other threads:[~2008-08-29 14:02 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-29 14:02 Matthew Wilcox [this message]
2008-08-29 14:06 ` USBIP protocol Andi Kleen
2008-08-29 22:31 ` Marcel Holtmann
2008-08-29 20:46 ` Matthew Wilcox
2008-08-29 20:51 ` Willy Tarreau
2008-08-29 14:30 ` Greg KH
2008-08-29 14:43 ` Matthew Wilcox
2008-08-29 14:54 ` Greg KH
2008-08-29 15:36 ` Matthew Wilcox
2008-08-29 15:53 ` Dave Higton
2008-09-03 4:25 ` Matthew Wilcox
2008-09-03 15:40 ` Alan Stern
2008-09-03 19:10 ` Matthew Wilcox
2008-09-03 20:15 ` Alan Stern
2008-09-04 21:48 ` Matthew Wilcox
2008-09-04 22:15 ` Greg KH
2008-09-05 3:26 ` Pete Zaitcev
2008-09-05 11:37 ` Tilman Schmidt
2008-09-05 15:05 ` Alan Stern
2008-09-09 0:53 ` Matthew Wilcox
2008-09-09 7:12 ` Steve Calfee
2008-09-09 7:33 ` Greg KH
2008-09-09 8:04 ` Greg KH
2008-09-09 15:21 ` Alan Stern
2008-09-03 15:57 ` Greg KH
2008-09-03 19:43 ` Matthew Wilcox
2008-09-04 2:41 ` Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080829140224.GC1968@parisc-linux.org \
--to=matthew@wil.cx \
--cc=bgmerrell@novell.com \
--cc=greg@kroah.com \
--cc=hirofuchi@users.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=usbip-devel@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox