[MUD-Dev] Re: mud client development systems

[J C Lawrence]

On Tue, 08 Dec 1998 00:50:47 -0600 
Sunny Gulati<sunnywiz at radiks.net> wrote:

> 1. I'm not an awesome C hacker.  Playing around with a driver,
> dealing with binary streams coming straight from a socket, scares
> me.  Especially when I don't have a crystal clear idea of my
> communications protocols.

Protocol design is really not that difficult.  Efficient protocol
design is another matter, as is secure protocol design.  The rules
and patter for protocol design are pretty simple, and rather
laborious.  Happily once you've gone around the ring a few times you 
can unfold most of the loops into mental space and do them while
commuting to work (I have a 50 mile commute):

  1) Build a finite state diagram for your system.  

  If you're not too familiar with the ligical basies for Finite
State Machines, don't worry.  Just figure out all the different
"states" that your protocol can be in (or youa re going to want it
to support), and them make a drawing showing all them and how they
relate.  Make sure that your links between states show clearly what
is required to move from one state to another.

  ObLesson: As this is a protocol, we're concerned with the
mechanics of _communication_.  When and if you get lost, hark back
to human speech and look at the structures used in human
interaction, such as simple acknowledgments and indications of
specific understanding to see what you might adapt.

  ObLesson: Communication requires a minimum of two ends: a source
point and a receipt point.  (You can also have multiple receipt
points).  Acknowledgments and other back-flow traffic really is a
whole new cycle of communication with new source points/receipt
points etc.  You'll probably find it a lot easier if you design the
system to be orthogonal at that level -- ie the low level mechanics
for sending a data packet in one direction are identical to the
mechanics for sending a ACK back in the reverse direction.

  2) Test your finite state machine.  

  Again, pretty simple stuff.  Sit down and think of eamples of the
types of things you are going to want to be able to do under this
protocol.  Now dry run those sorts of transactions thru your state
diagram and ensure that it actually *is* possible.  (I've designed
many protocols that were utterly useless for the reason I developed
them.  The old can't-get-there-from-here problem is *really* easy to
create)

  ObLesson: Keep very careful track of what data every "node" in the
diagram has and how it got it.  It is very easy to think up really
neat looking systems that rely on omniscient programs to pull magic
data out of the air when they need it.

  3) Diddle and extend your finite state machine and its accompnying
diagram (repeating #1 and #2) until you can do everything you think
you are going to want to be able to do with your design.

  4) Now look at your diagram and machine with a critical eye.  Look 
for states that aren't ever actually used.  look for states that
need not be used (ie can be replaced with other already-present
states and achieve the same end).  Attempt to simplify and reduce
your state diagram as much as possible.  Then do the #1 - #4 tango a 
few more times until you think you've really got it right.

  5) Now go over your system and look at the way that data moves
thru it.  The diagram details how the communication is _controlled_.
What we are interested in now is the payload of that communication.
What data is being moved, how does it get where it gets, is it
actually needed there or is it useless (ie wasted), and how can each
end of the transactions (ie state transitions) know that the right
data was communicated and that what was received was the same as
what the sender sent, _and_ (and this is the really tricky bit),
that what the receiver understands as a result of that data matches
the intended understanding.  This is more than simple error
correction, this is also an attempt to protect against
man-in-the-middle and spoofed data attacks.

  ObLesson: An old hack to an old C/S-style empires whose name I
forget was to send it forged data packets indicating that your
peasents were rioting/starving/dieing.  On the surface this data was
useless to everybody except the NewsFlash generation routines.
Under the covers however that data got factored into "morale"
indicators that other players had of your country and you could
thereby ensure that other players thought your country was in worse
shape than it was.  

  Translation: Put in generic data state veracity checking.  These
are purely cross check systems that don't validate data directly,
but instead do comparisons of the form:  

    Receipt point: "Your data indicates that XXX is also true.  Is
XXX true?"

    Sender:  "Yes/No XXX is/is_not true."

    Receipt point: "Ahh, somehing has/has_not lied to me.  Let us
re-authorise and resync."

> 2. I have to keep the project small and manageable with little
> itty bitty steps.  I simply don't have the bandwidth to do a large
> project (not while being a programmer for a living too).  My
> bandwidth is about an hour a day if i'm lucky. Weekends I can
> squeeze in another 4-5 hours. :) And I defintely want to have this
> get somewhere, rather than ball up into a big thing and stall.

I find that sufficient design work helps this process immensely,
especially if you are careful to build your system from
semi-autonomous components as you can then write and test each
component semi-individually on short development cycles with
reasonably high accomplishment reward rates"Right!  That's done and
working!".

> That being said, here are some further ruminations.

--
J C Lawrence                              Internet: claw at kanga.nu
(Contractor)                             Internet: coder at kanga.nu
---------(*)                    Internet: claw at under.engr.sgi.com
...Honorary Member of Clan McFud -- Teamer's Avenging Monolith...