Re: [OpenAFS-devel] dcerpc.net - freedce

[Luke Kenneth Casson Leighton]

hi there,

okay, checked the afs-devel archives to get your first
reply, marcus.

okay.  regarding DCE/RPC using ASN.1, well, as i said,
it doesn't use ASN.1 for function call marshalling/
unmarshalling.

regarding packet transfers, these are done in
'protocol data units', which when you make a
function call, the data is split up into regular
sized chunks, a header slapped on the front (16
bytes) and sent over-wire.  header says what opcode,
first pdu, intermediate pdu, last pdu, usual stuff.

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' :)

regarding ms and k5, UH!  idiots.  they even quoted
to me 'uh, well, DCE uses a PAC so we're not the
only ones' well DUUR, guys, they did it in a
kerberos-friendly and backwards-compatible waaaay.

rrrr.

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.

DCE/DFS is slow, file-insecure, and now you tell me
it's cumbersome, too.

... well, _that's_ encouraging: makes it worthwhile
to do something a bit better :)

[but i _do_ like the per-file ACLs.  *sigh*]


yes, the dce 1.22 codebase does contain a working
server, and working cell directory services, and
time server etc. etc.  however, of course, to
get a working and useful client, you have to have
kernel-level tie-ins (or userspace hooks like
in linux) which of course hasn't been done.

regarding your questions:

1) would i try to be compatile with AFS-4?

don't know, i'm not really the best person to ask.
i know dce/rpc extremely well, and what it can
do.

i tend to take the path of least resistance when
it comes to programming, esp. when dealing with
O(10^^5 or ^^6) LOC projects.

so, following that logic:

- AFS-4 is currently still only available under
an Open Group license, until such time as they
resolve their legal negotiations.  therefore,
implementing AFS-4 would have to be done from
scratch, like Transarc did, or waiting.

i'm not into waiting all that much, and from-scratch
is hard work.

- AFS-3 is an existing open source project, with
lots of people working on it, _and_ using it,
_and_ it's available for linux (cool).

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
and locator service components, comparing against
the AFS-4 codebase to get some clues on the
locations to investigate.  then choose whether
to convert the AFS-3 locator services _as well_
to DCE/IDL, or to replace them with DCE Cell
Directory Services, whoops, can't do that:
CDS is part of the dce 1.22 codebase/suite :)

is this getting to be a big task, or is it still
a small, manageable one?

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
of implementations that can be used.  one is
to auto-generate inline code, and the other
is to auto-generate a table (in DCOM / MSRPC
terminology, a 'type library') that is then
used with offsetof macros to pack / unpack
structures with a helper function.
the helper function basically reads an
entry in the table to decide what to pack or
unpack next, looping until it hits an end-of-
structure marker in the table.

both approaches - the inline code and the
type-library plus helper function - are pretty
efficient _and_ they are single pass _and_
you could potentially optimise so that you 
can send or receive data out or from over-wire
from or to a buffer as soon as it's full, whilst
still not having finished marshalling or unmarshalling.

bit tricky, wouldn't like to be the one to
implement it unless i had a lot of spare time
on my hands, but it's quite feasible :)

3) what about compatibility with AFS-3.

well, compatibility with AFS-3 seems to be
the most attractive choice.

when-or-if AFS-4 becomes available under an
open source license, we'd be in a much
stronger position to investigate that codebase,
having a firm and working understanding of
dce/rpc (by having created AFS-3-dce/rpc) by
that time.

i mean, what i _really_ don't want is to
have to manage - or expect anyone else to -
manage two very similar codebases, esp. not
at the 100,000 LOC+ level.  it's not bleedin'
funny, i can tell you (i've tried tracking two
similar 300,000 LOC codebases and that's why
i'm not laughing).

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.

luke

_______________________________________________
OpenAFS-devel mailing list
[EMAIL PROTECTED]
https://lists.openafs.org/mailman/listinfo/openafs-devel