[OpenAFS-devel] dcerpc.net - freedce

[Marcus Watts]

Jeffrey Hutzelman <jhutz@cmu.edu> writes:
> 
> About the only thing Rx has in common with sunrpc is XDR, which is pretty
> much identical in both protocols (enough so that kernel-rx does not
> include its own XDR, but instead depends on the one already present in the
> kernel for supporting NFS).

rx also shares rpcgen -- rxgen *is* rpcgen with "extra" stuff.
I think it's still possible to use rpcgen to produce straight sun
stuff, although the documentation on all that is pretty skimpy.

Code re-use is a cool thing, and it's a really cool thing the
developers of rxgen were able to do so.  Even today, many opensource
projects don't "get" the notion of code re-use.  It would, for
instance, be difficult to pull the ASN.1 parsing code out of openldap,
use it to parse, say, K5 tickets, and distribute the result as
part of some other package.  (This is why "Artistic" licenses
suck, but that's a whole 'nuther rant.)

> > DCE RPC uses ASN.1, which is definitely less efficient at storing data
> 
> That's not fair.  ASN.1 has a number of distinct advantages over XDR,
> particularly when you are trying to design an extensible protocol or use
> datatypes that don't fit neatly into the usual native ones.  And it can be
> quite efficient, depending on what encoding rules you use.  Of course,
> you're right about people mis-implementing it left and right.

Oh, I don't know about "fair".  That's a sort of subjective
"quality of life" thing with a whole bunch of buried assumptions,
so differently people will see that differently.  I do know
that ASN.1 is difficult to read from a debugger without some
tool to take byte streams and decode them.  I also know lots
of people who have really bad things to say about ASN.1, because
I designed another protocol to use it (got to learn about
some of those interesting hooks for extension) and they said
all those bad things.

But it seems that's a moot point if DCE/RPC uses NDR (though
I could have *sworn* it used ASN.1 -- am I remembering ancient
history or just confused?)...  At a really brief glance through
opengroup's pages, NDR also looks like using an elephant to kill
a mosquito, but I suppose it's at least a more streamlined elephant.
NDR at least seems to be better about some of the most annoying
features of ASN.1, like self-encoding integer lengths (if you
get 5 bytes, will it fit into an int*32 & what do you do if it
doesn't?)

In any event, that still leaves my previous assertion:  AFS 3, and
OpenAFS which Is AFS 3, was *never* based on DCE RPC, and the data
structures and server primitives are *not* compatible with DCE DFS.
DCE DFS is indeed based on AFS, but it's based on AFS *4*, which is
radically different in certain respects from AFS 3, at *every* level,
not just the RPC layer (or the "cds" layer which is, honestly, kinda
lame in AFS 3).  Teaching OpenAFS is *not* a matter of "putting back"
DCE RPC, because it was never there.  It probably wouldn't be real hard
to use DCE RPC (main expense: using a different thread package) but the
result of switching OpenAFS over to use DCE RPC won't interoperate with
native AFS, nor will it interoperate with DFS, but will in fact be its
own new animal.  That doesn't mean it's a *bad" new animal, but it
doesn't necessarily mean anything good, and does mean it has to stand
on its *own* merits, not those of either AFS 3 or DFS.
	[ When you see things like "ubik" or "bozo" (I think one or both of
	  those carried forward) that are part of DCE DFS, and later see them
	  in OpenAFS, what you saw in DCE DFS was the "more advanced" version,
	  and the version in OpenAFS is the ancestor, or more properly, a "less
	  evolved" descendent of a common ancestor (probably AFS 3.1 with perhaps
	  some cross-polination since.) ]

				-Marcus Watts
				UM ITCS Umich Systems Group