From: David Robinson (David.Robinson@sun.com)
Date: 12/19/02-10:45:49 PM Z
Message-ID: <3E02A07C.6010000@Sun.COM> Date: Thu, 19 Dec 2002 22:45:49 -0600 From: David Robinson <David.Robinson@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