[AFS3-std] Re: Standardization of the AFS3 protocol

[ted creedon]

There are 2 sets of skills required:

1. Computer science - understanding the protocol - that's for others
2. Written - making publication quality English of the above 

End of thread.

tedc

-----Original Message-----
From: afs3-standardization-bounces@openafs.org
[mailto:afs3-standardization-bounces@openafs.org] On Behalf Of Jeffrey
Hutzelman
Sent: Wednesday, February 22, 2006 8:59 AM
To: ted creedon
Cc: afs3-standardization@openafs.org; afs3-protocol@stacken.kth.se
Subject: RE: [AFS3-std] Re: Standardization of the AFS3 protocol

On Wed, 22 Feb 2006, ted creedon wrote:

> Yes but revisions should be indicated with margin stripes and code
snippets
> in verbatim.

Ted, do you have any experience at all with defining and standardizing
network protocols?

Perhaps more importantly, do you have any understanding of the inner
workings of the rx protocol?

These are serious questions.


The documentation David is looking for is not "to do X, type command Y" or
even "I made these changes to the code today in the hopes of achieving
goal foo".  What he is looking for is complete details of the exact bits
that appear on the wire and their semantics, including which combinations
are required, recommended, or prohibited, how all the edge cases work, and
a description of the abstract state machine required to implement the
protocol correctly.

In other words, he wants all the documentation he would need to write a
correct, interoperable implementation from scratch.  That is, a protocol
specification.


Unfortunately, no such specification exists today.  All we do have is a
reference implementation, which itself is quite hairy and difficult to
understand, especially if one is not already familiar with the protocol
and its history.  There are many warts related to backward-compatibility
with earlier versions of the code.  There is also quite a lot of code
related to features that seemed like a good idea at the time, but actually
were not, and should never be enabled.  A good protocol specification
would describe these, but would recommend against doing them, if not
outright prohibit doing so (for example, deliberately sending IP datagrams
several times the MTU size)

Writing down a protocol specification for Rx will require sifting through
the code, including all three current branches (IBM AFS, OpenAFS, and Arla
all use diverging versions of Rx deriving from the same original codebase)
as well as historical versions, figuring out what's there because it's
needed for the protocl to work, what are/should be optional vs required
features, and what are simply artifacts of the implementation.  Rx is a
complex, multi-layered protocol, and it is likely that documenting it
correctly will require more effort than all of the AFS RPC protocols put
together.

Still, I think the effort is worthwhile, and I'm willing to spend some of
my own time on it, if others are as well.  I would very much like to see a
truly independent complete, interoperable implementation of Rx, which is
something that we do not have today.

-- Jeff


_______________________________________________
AFS3-standardization mailing list
AFS3-standardization@openafs.org
//michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization