Re: USBIP protocol

[Matthew Wilcox]

On Fri, Aug 29, 2008 at 07:54:07AM -0700, Greg KH wrote:
> On Fri, Aug 29, 2008 at 08:43:54AM -0600, Matthew Wilcox wrote:
> > On Fri, Aug 29, 2008 at 07:30:17AM -0700, Greg KH wrote:
> > > On Fri, Aug 29, 2008 at 08:02:24AM -0600, Matthew Wilcox wrote:
> > > > 
> > > > 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.
> > > 
> > > USB is fundamentally packet-based, so it kind of fits very well.
> > 
> > Erm, did you not read what I wrote?  USB is packet based.  TCP isn't.
> > We shouldn't be using TCP here.
> 
> Sorry, early morning, no coffee yet...
> 
> I think in the end, we should still use TCP otherwise you just end up
> reinventing it with UDP :)

Which brings us to the alternate -- that we need better framing in the
protocol.

> Ok, switch it all to be little endian, not a bit deal.

No, but it does need agreement ;-)

> > > >  - 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.
> > > 
> > > Is that a real problem?
> > 
> > Yes, it really is.  It complicates the protocol, complicates the
> > implementation, introduces unnecessary state, and makes it impossible to
> > renegotiate on the same connection.
> 
> Fair enough, patches welcome :)

Patches don't seem appropriate for a design discussion.  I'm more than
happy to make suggestions about how to unify the two protocols.  I'll
send a followup to this with some ideas.

> > Even if we don't go through the RFC process, just writing down the
> > on-wire protocol should be mandatory for taking this kind of thing into
> > the kernel.
> 
> Why, isn't the actual implementation better than a document?  :)

Surely you know that writing things down forces you to understand it
better?

-- 
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."
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/