[OpenAFS-devel] dcerpc.net - freedce

[Marcus Watts]

Luke Kenneth Casson Leighton <lkcl@samba-tng.org> writes:

...
> the PDU size is negotiated.  typically, NT negotiates
> 0x1630 bytes, AS/U negotiates 0x0800, freedce / dce
> 1.1 negotiates 0x1000.  this can be easily changed,
> i should imagine, to suit the network conditions etc.,
> however i seem to recall vaguely seeing some comments
> that said 'this would be nice to implement' :)

Figuring out the MTU for TCP/IP is tricky.  Actually, for RX (and I
assume DCE RPC) this would most likely be UDP/IP.  TCP does path MTU
discovery by sending various sized packets with "DF" set, looking for
the ICMP returns, and downsizing and re-transmitting, all inside the
kernel.  RX is screwed 2 ways: (1) there's no good portable way (I
think) to capture ICMP responses to UDP packets that bounce, and (2) RX
packages things up in "packet" units, so if it has to retransmit in
smaller pieces, it's screwed.

For this to work right in DCE RPC, it needs to track data sent in byte
quantities, such that it can dynamically downsize packet size without
confusing the other end that might see an older "big" packet that
managed to make an end-run around some MTU constriction (say, caused by
a router that's got a route that's flip-flopping.) Then, DCE RPC would
need to find a way to capture ICMP packets sent in response to UDP.
It'd be nice if there were a udp option to make this happen, but I
don't see it.  A raw socket is a possibility, though it wouldn't work
for userland tools...

Anyway, I think that's why you see comments like "this would be nice"
in the source...

> to answer your point about dfs source being released:
> yes, it has.  it's available from the open group's
> web site.  the license is 'educational' purposes.
> i.e. you can look, you can compile, you can use,
> you can _not_ distribute, especially binaries.
> you have to get a license (pay $) to do that.

Educational license, eh?  Just like solaris, ya.  Well, I suppose it
would be possible to gamble they'll release it more openly in the
future and work ahead, but I don't know if I'd want to gamble on
lawyers being reasonable.

...
> so, porting AFS-3 would be an easier job than
> AFS-4.
> 
> my initial estimation of the tasks involved
> would be to start with the IDL files, converting
> those to DCE/IDL.  identifying the security
...
> 
> is this getting to be a big task, or is it still
> a small, manageable one?

Switching AFS3-3 to use IDL et al is quite doable, but it *will* be its
own animal.  I think that it would be fine for educational purposes or
a closed environment.  Whether it will be useful to others in a larger
sense is another question, and would depend on what you can do in terms
of backwards compatibility & forwards features to make it worth
people's whiles.  For instance, if you can make pipes and path MTU
discovery work nicely, that would be at least a small enticement.

...
> 
> 2) what, if anything, to do about increased footprint?
> 
> well, this assumes that DCE/RPC uses ASN.1 for
> data transfer, which it doesn't.
> 
> NDR is pretty efficient.  there are two kinds
...

The client side footprint comes not from the packet size, but from the
use of CDS and other DCE services.  I believe one of the pieces is
something like sun's portmapper.  The AFS 3 equivalent of CDS is a flat
file (CellServDB) and mount points in root.afs, both of which get
maintained by hand.  That means tiny code in the clients, no code in
the server.  The AFS 3 equivalent to portmapper is fixed port
addresses.  Clients just "know" file servers live on port 7000, etc.
The DCE equivalents to do all this seem to require a lot more code.  On
the server side, I think that translated into needing very well endowed
servers with twice as much memory and CPU to get the same performance.
'Course, these are both a lot cheaper today.

> 
> 3) what about compatibility with AFS-3.
..
> so, if at all possible, simply adding in
> DCE/RPC as a compile-time or even a run-time
> option to AFS-3, and other than that not
> even _touching_ the file-serving code _at all_,
> well, if that's possible, i'll be v. happy.

Actually, I meant compatibility at run-time, not in the source.
IE, I'm still running transarc RX binaries, you're running
DCE-RPC, can we talk?

Whatever you do, you definitely can't totally hide this from the AFS
code.  I suppose you could write a wrapper to make DCE threads look
like LWP, and another wrapper to translate .xg (rxgen) files into
whatever IDL wants.  That might account for 99% of what you want, but
there are bound to be messy spots.  Certainly all the stuff in AFS that
knows about 8 byte DES keys and K4 tickets is going to have to change.

				-Marcus Watts
				UM ITCS Umich Systems Group