Re: RPC...

Hi Tom,

> We're debating some issues of high performace data request/transfers
> using either RPC or roll-our-own socket code.  The worst-case
> is something like reading world-wide surface data out of a netCDF
> or MD file.  The 'cliet' application can only handle one observation
> at a time, so it's interface to the communications underworld
> will consist of a "give me the next record/observation'.

Our experience with using RPC's versus socket-level code is that RPC's are a
lot easier to use and result less code to maintain.  Our LDM system uses
RPCs and there is no performance issue in their use.  It's just more natural
for client/server architectures to use RPCs instead of messages.
Socket-level code is lower-level and requires that you grovel in the details
of things that RPCs handle for you.  It's also possible to grovel in the
details with RPCs when you need to (e.g. setting network timeouts, batched
RPCs, etc.), but it's not usually necessary.  With socket-level code, I
think you would still end up implementing your own RPC architecture if you
follow the client/server model.

> I know in the early days of netCDF, you were using an RPC-based
> approach.  Is this still true?  If it is, can you give me any
> words about the senerio above (other than, "don't do it that
> way", of course).

We never used RPCs with netCDF, but recently an oceanographer we have worked
with has implemented a netCDF server by supporting the netCDF interface
through RPCs.  We had thought of doing this, but never got around to it.

We do use XDR for data representation in netCDF, and ONC RPCs also use XDR,
so maybe that's what you remember.  The other kind of RPCs, DCE RPCs, don't
use XDR.

--Russ