From: Noveck, Dave (Dave.Noveck@netapp.com)
Date: 12/20/02-11:11:10 AM Z
Message-ID: <C8CF60CFC4D8A74E9945E32CF096548A0729DD@SILVER.nane.netapp.com>
From: "Noveck, Dave" <Dave.Noveck@netapp.com>
Subject: RE: RPC? XDR?
Date: Fri, 20 Dec 2002 09:11:10 -0800
It seems to me that the following summarizes what has
happened:
First Rob said:
Using RPC hurts this. Let's not use it.
Later some people said:
Using RPC doesn't hurt. Let's use it.
However Brent said:
Using RPC doesn't help. Let's not use it.
I hope I haven't misrepresented anybody's position.
Except for Rob, there seems to be a consensus that using
RPC neither helps nor hurts and that the disagreement seems
to be what conclusions to draw from that.
-----Original Message-----
From: David Robinson [mailto:David.Robinson@sun.com]
Sent: Thursday, December 19, 2002 11:46 PM
To: nfsv4-wg@sunroof.eng.sun.com
Subject: RPC? XDR?
RPC or not?
RPC the protocol is more than capable and does not
have much more overhead than most other compareable
protocols. When doing a streaming protocol with the
ability to recover and restart in the face of errors
or connection loss, you will have effectively what is
in an NFS/RPC header. The biggest cause of inefficency
are the implementations and not the protocol. As an
example, many kernel RPC implementations contain the
full complexity to handle any arbitrary RPC protocol
when in reality they only support one (NFS) maybe two
protocols. Efficient implementations are possible,
and I suspect hardware versions such as Bluearc are
examples. The protocol is not the issue, poor implementations
(especially those starting with the Sun reference source)
are.
The other part of RPC is how the upper level protocol
dictates its use. For many operations like an NFS getattr
it usually expects a response before issuing a subsequent
request. But nothing in RPC prevents a client from
issuing a 100 READ requests before looking for a response
and keeping the pipeline 100 deep. Except poor implementations.
XDR?
Personally I hate XDR, it is a bad mix between a standard
protocol header description (i.e. iSCSI) and a self describing
format that does neither well. If you toss out the esoteric
bits that few protocols use (float, pointers) it is really
just a language to describe a fixed headers in network byte
order. Dropping variable sized objects such as arrays and
unions and the complexity is no greater than that of a standard
protocol like iSCSI. (it is probably possible to describe iSCSI
in terms of XDR) The worst part of XDR is that it allows lazy
protocol design with inefficient layout or hard to automate
encode/decode. Combine that with lousy implementations that
make recursive function calls just to decode 4 bytes and
you will find the root of most complaints.
So while I don't like XDR, if the protocol designers pay
attention to how the bits actually layout on the wire
(e.g. make 8 byte quantities start on 8 byte boundaries)
using XDR as the description language is reasonable.
Given the framework and investment in RPC and already defined
security mechanisms, I would stick with RPC unless someone
can show how it won't meet the needs. Citing bad implementations
should not be a consideration.
-David
This archive was generated by hypermail 2.1.2 : 03/04/05-01:50:44 AM Z CST