[OpenAFS-devel] dcerpc.net - freedce

[Luke Kenneth Casson Leighton]

On Tue, Aug 14, 2001 at 12:03:52PM -0400, Ted Anderson wrote:
> On Mon, 13 Aug 2001 21:31:14 -0400 Marcus Watts <mdw@umich.edu> wrote:
> > DCE RPC uses ASN.1, which is definitely less efficient at storing data
> 
> I don't think this is true.  

trust me: it is.  i had to implement NDR, in samba.  hand-coded,
took 3 years.

and when i got to about... 70,000 lines of code, i got bored
and decided 'this is silly' and started looking for a compiler.

unfortunately, there wasn't one, at the time, that was any
good.  then freedce came along, started to mature, and it's
now in a useable state.

which is why i approached you guys to see if anyone's
interested in adding dce/rpc, just like Transarc did.

see, there _is_ a reason for this.

... see, for a long time, like about... three to four
years, now, i've had this dream about having an alternative
network file system for both nt and unix that _isn't_
SMB, and isn't NFS.

now, the crazy thing is that AFS-DCE/RPC is about the
closest simplest option, aside from writing a completely
new file server system, from scratch.

ms already has DCE/RPC, so, using MIDL and NT's extremely
good DCE/RPC support, porting AFS-DCE/RPC to NT (instead of
porting AFS with RX to NT) should be a heck of a lot easier.

[..now someone's going to tell me it's already been done :)]

... am i way off course here? :)


> DCE/RPC uses Kerberos 5 for security, and
> the K5 ticket format uses ASN.1.  

yes, that's right.  that, however, is just one plug-in
security component.

kerberos is capable of being used 'encapsulated' in
other transports (rfc 1510?) which is what has been done.

so, just one of the (5 known) dce/rpc-negotiable security
components is dce/rpc, and, well, kerberos as you say is
ASN/1, so there has to be a small amount of kerberos-aware
logic in the dce/rpc, to decode the PAC (privileged
authentication certificate?  it contains user info, basically.
am i right?)

i'm just in the process of adding NTLMSSP to freedce,
so it will 'have' urr... well, ms sort-of chose their
own NDR-not-quite-compatible format for the NTLMSSP
marshalling/unmarshalling, daft buggers.

but for the actual function-call parameters / structure
transfers?  no, the default data representation is
definitely NDR, and noone's ever bothered to add a
second data representation syntax.


> However, the RPC marshalling code uses
> something similar to XDR.  

[it's named NDR - network data representation]

similar to? ... i've never examined XDR on-wire, so i can
only suspect that it is.  i do know that XDR is nowhere
as feature-rich as NDR, though.

> One of the differences from XDR is that
> doesn't use network byte order, but, I think, sender byte order.
 
sender byte order.  yes.  'receiver makes right' is the
term: they had to use RMR because 'sender makes right' is
patented [*duur*!  they patented the wrong one! SMR requires
a round-trip negotiation, whereas RMR you can just start
immediately :)]

> Otherwise, the clarification of AFS vs. DFS RPC history is correct.

[cool.  always like to get my stories right :)]

luke