[OpenAFS-devel] dcerpc.net - freedce

[Marcus Watts]

Luke Kenneth Casson Leighton <lkcl@samba-tng.org> writes:
> i don't know if you're aware of this, but DFS was originally
> using DCE/RPC and it was called DCE/DFS.
> 
> when it became AFS, the dce/rpc mechanism was replaced with
> an AFS-specific RPC mechanism.
> 
> dcerpc.net is now hosting freedce - a GPL version of dcerpc 1.1.
> 
> i was wondering if anyone would be interested in putting
> dce/rpc back into AFS?

Actually, it was the other way around.

Andrew File System was originally developed at CMU in partnership with
IBM.  It was then spun off into a separate organization, transarc.
Around 1990, transarc was selling AFS 3.1.  This was (just like current
AFS 3 based releases includeing openafs) based on RX, which is actually
not entirely its own creation but heavily based on SUN RPC.  There
are traces of support for an older protocol ("r"?) in some parts
of AFS 3, which probably predate AFS 3.  I think I once saw some
documentation for some of the AFS 2 utilities which ran under RT/AOS 3.

Meanwhile, transarc was also working on something called "AFS 4", which
turned into the DFS component of DCE.  AFS 4/DFS was a complete rewrite
of AFS 3.  As part of the DCE environment, it used DCE RPC, security,
and etc.  It's also not compatible with AFS 3- serving both
environments is possible, but not pretty.  Just as a "for instance",
DFS has per-file acls, AFS 3 has per-directory acls.  DFS is definitely
much more than a matter of sliding DCE RPC underneath AFS 3.

The main problem with DCE/DFS is it seems to be much more heavy-weight
and cumbersome, without any clear benefits in terms of functionality.
There were loads of interesting minor benefits, but for most sites,
I don't think this outweighed having to buy much more expensive
server platforms, using up more per-client space as well, and
dealing with a complicated migration plan.

DCE RPC uses ASN.1, which is definitely less efficient at storing data
than SUN XDR, which is what AFS uses today.  "Less" efficient might
mean larger packet sizes, and/or increased CPU doing data
marshalling/unmarshalling.  There are a ton of ways to mis-inplement
ASN.1 because it's not well defined (apparently nobody reads the actual
standards because they're $$$ and opaque.) It is also easy to mis-use
ASN.1 in ways that are dramatically less efficient, because it does
such a good job of hiding the actual implementation details from the
designer.  DCE RPC should at least do a good job of avoiding low-level
consistency issues.  But that in turn raises the interesting issue of
MicroSoft and what it might have planned for DCE RPC -- there have
already been some notable unpleasantness with K5 (and microsoft's
proprietary extensions), and Java ( " " " ).

I seem to recall at one point DFS source was released.  Do I
remember wrong or something?  I think whatever was released
wasn't sufficient to actually build a useful DFS workstation
client or server, but perhaps with "freedce" that's no longer true.

In any event, I think the points you'd need to address would be:
	1- would you try to be compatible with existing DCE/DFS
		aka "AFS 4"?
	2- what, if anything, would you do about the increased
		server/client footprint that DCE seems to require?
	3- what about compatibility with existing AFS 3?

					-Marcus Watts
					UM ITCS Umich Systems Group