On Thu, Nov 04, 1999 at 07:45:29AM +0100, Tom Ivar Helbekkmo wrote:
> One thing I've failed to understand from browsing the Coda
> documentation: _why_ is there a private re-implementation of RPC? A
> brief summary of the reasons for this decision would be interesting,
> if someone has the time to respond. (They must have been rather
> powerful, to be worth absorbing the cost of implementation and
> debugging, I assume? This is difficult territory, and I was not
> surprised back when I tried to get Coda running under NetBSD before
> you folks did, and I gave up when, after many hours of debugging and
> modifying rpc2, I still failed to get authentication working.)
>
> -tih
> --
> Popularity is the hallmark of mediocrity. --Niles Crane, "Frasier"
I surely don't know all the reasons, but maybe some of them.
- RPC2 was used by AFS2.
Some of the system on which Coda is built was jumpstarted by using
the AFS2 codebase to quickly get to a working implementation.
- Available technology the the time it was developed.
TCP was in it's infancy, memory-usage and filedescriptor usage were
the limiting factors for any network service. (think of select that
could only handle 32 filedescriptors)
- Design objectives.
You could as well ask, why DCOM, Corba, RX, etc. Or for that matter
C++, Java. Or NFS/AFS/Coda, or Windows/Linux :)
Also the multirpc implementation does a very good job at sending a
single message to a large group of peers, without using multicast. This
is vital for the callback breaks. Also the streaming 'side-effects' for
bulk datatransfer, which work very well when sending one data stream to
a group of servers, as used by Coda's active replication. There is
simply no serious alternative without losing functionality. Which is
also the reason I was mentioning the possibility of layering
rpc2-on-tcp. That is not to preserve compatibility, but to preserve
functionality of the existing implementation.
- Research.
Multiple implementations of the same concept improve overall
understanding of the underlying theorems.
- Availability of alternatives.
Maybe there weren't good alternatives available 12-15 years ago.
- Portability and support.
Ok, this is a bad excuse, but I heard it a couple of times and the
reasoning goes a bit like this.
What if we use product xxx to handle yyy. Well, we could, but what
if they don't port xxx to platform zzz. Or what if they stop fixing
bugs we find. And at some point, for some reason, implementing,
bugfixing, and porting the code yourself looks simpler than leveraging
off other people's sweat and tears. Luckily, the idea's behind OSS
seem to be changing that rapidly.
f.i. switching Coda-lwp to pthreads is possible, I even have a fully
working `glue'-layer, but we lose _all_ windows ports until a pthread
compatible api is available on those platforms. Also GNU Pth seems to
work exactly like LWP, and could actually be used as a drop-in
replacement. But as it is, LWP is fast, relatively bug free ;), and
the only drawback at this time, as far as I'm concerned, is that gdb
isn't able to switch the stacks of the LWP-threads.
Also recently persistent memory stores have started popping up (hmmm,
how old is RVM by now?), Coldstore, texas, etc. They seem to require
compiler/linker hacks and are more focussed on C++ programs.
Jan
btw. You hacked on Coda back in the Mach day's? Wow, impressive.
