<!-- MHonArc v2.4.4 --> <!--X-Subject: [MUD-Dev] Re: mud client development systems --> <!--X-From-R13: X Q Znjerapr <pynjNhaqre.rate.ftv.pbz> --> <!--X-Date: Fri, 11 Dec 1998 22:58:38 -0800 --> <!--X-Message-Id: 199812120305.TAA83834#under,engr.sgi.com --> <!--X-Content-Type: text/plain --> <!--X-Reference: 2.2.32.19981208065047.006d66ac#pop,radiks.net --> <!--X-Head-End--> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <html> <head> <title>MUD-Dev message, [MUD-Dev] Re: mud client development systems</title> <!-- meta name="robots" content="noindex,nofollow" --> <link rev="made" href="mailto:claw#under,engr.sgi.com"> </head> <body background="/backgrounds/paperback.gif" bgcolor="#ffffff" text="#000000" link="#0000FF" alink="#FF0000" vlink="#006000"> <font size="+4" color="#804040"> <strong><em>MUD-Dev<br>mailing list archive</em></strong> </font> <br> [ <a href="../">Other Periods</a> | <a href="../../">Other mailing lists</a> | <a href="/search.php3">Search</a> ] <br clear=all><hr> <!--X-Body-Begin--> <!--X-User-Header--> <!--X-User-Header-End--> <!--X-TopPNI--> Date: [ <a href="msg00952.html">Previous</a> | <a href="msg00954.html">Next</a> ] Thread: [ <a href="msg00940.html">Previous</a> | <a href="msg00954.html">Next</a> ] Index: [ <A HREF="author.html#00953">Author</A> | <A HREF="#00953">Date</A> | <A HREF="thread.html#00953">Thread</A> ] <!--X-TopPNI-End--> <!--X-MsgBody--> <!--X-Subject-Header-Begin--> <H1>[MUD-Dev] Re: mud client development systems</H1> <HR> <!--X-Subject-Header-End--> <!--X-Head-of-Message--> <UL> <LI><em>To</em>: <A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A></LI> <LI><em>Subject</em>: [MUD-Dev] Re: mud client development systems </LI> <LI><em>From</em>: J C Lawrence <<A HREF="mailto:claw#under,engr.sgi.com">claw#under,engr.sgi.com</A>></LI> <LI><em>Date</em>: Fri, 11 Dec 1998 19:05:28 -0800</LI> <LI><em>Reply-To</em>: <A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A></LI> </UL> <!--X-Head-of-Message-End--> <!--X-Head-Body-Sep-Begin--> <HR> <!--X-Head-Body-Sep-End--> <!--X-Body-of-Message--> <PRE> On Tue, 08 Dec 1998 00:50:47 -0600 Sunny Gulati<sunnywiz#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#kanga,nu (Contractor) Internet: coder#kanga,nu ---------(*) Internet: claw#under,engr.sgi.com ...Honorary Member of Clan McFud -- Teamer's Avenging Monolith... </PRE> <!--X-Body-of-Message-End--> <!--X-MsgBody-End--> <!--X-Follow-Ups--> <HR> <!--X-Follow-Ups-End--> <!--X-References--> <UL><LI><STRONG>References</STRONG>: <UL> <LI><STRONG><A NAME="00940" HREF="msg00940.html">[MUD-Dev] Re: mud client development systems</A></STRONG> <UL><LI><EM>From:</EM> Sunny Gulati <sunnywiz#radiks,net></LI></UL></LI> </UL></LI></UL> <!--X-References-End--> <!--X-BotPNI--> <UL> <LI>Prev by Date: <STRONG><A HREF="msg00952.html">[MUD-Dev] Re: MUD Design doc (long)</A></STRONG> </LI> <LI>Next by Date: <STRONG><A HREF="msg00954.html">[MUD-Dev] Re: mud client development systems</A></STRONG> </LI> <LI>Prev by thread: <STRONG><A HREF="msg00940.html">[MUD-Dev] Re: mud client development systems</A></STRONG> </LI> <LI>Next by thread: <STRONG><A HREF="msg00954.html">[MUD-Dev] Re: mud client development systems</A></STRONG> </LI> <LI>Index(es): <UL> <LI><A HREF="index.html#00953"><STRONG>Date</STRONG></A></LI> <LI><A HREF="thread.html#00953"><STRONG>Thread</STRONG></A></LI> </UL> </LI> </UL> <!--X-BotPNI-End--> <!--X-User-Footer--> <!--X-User-Footer-End--> <ul><li>Thread context: <BLOCKQUOTE><UL> <LI><STRONG>[MUD-Dev] Re: mud client development systems</STRONG>, <EM>(continued)</EM> <ul compact> <LI><strong><A NAME="00921" HREF="msg00921.html">[MUD-Dev] Re: mud client development systems</A></strong>, Bruce Mitchener, Jr. <a href="mailto:bruce#cybersight,com">bruce#cybersight,com</a>, Mon 07 Dec 1998, 18:50 GMT </LI> <LI><strong><A NAME="00923" HREF="msg00923.html">[MUD-Dev] Re: mud client development systems</A></strong>, Benjamin D. Wiechel <a href="mailto:strycher#toast,net">strycher#toast,net</a>, Mon 07 Dec 1998, 19:00 GMT </LI> <LI><strong><A NAME="00939" HREF="msg00939.html">[MUD-Dev] Re: mud client development systems</A></strong>, Sunny Gulati <a href="mailto:sunnywiz#radiks,net">sunnywiz#radiks,net</a>, Tue 08 Dec 1998, 06:49 GMT </LI> <LI><strong><A NAME="00940" HREF="msg00940.html">[MUD-Dev] Re: mud client development systems</A></strong>, Sunny Gulati <a href="mailto:sunnywiz#radiks,net">sunnywiz#radiks,net</a>, Tue 08 Dec 1998, 06:49 GMT <UL> <LI><strong><A NAME="00953" HREF="msg00953.html">[MUD-Dev] Re: mud client development systems</A></strong>, J C Lawrence <a href="mailto:claw#under,engr.sgi.com">claw#under,engr.sgi.com</a>, Sat 12 Dec 1998, 06:58 GMT </LI> <LI><strong><A NAME="00954" HREF="msg00954.html">[MUD-Dev] Re: mud client development systems</A></strong>, Per Vognsen <a href="mailto:vognsen#post10,tele.dk">vognsen#post10,tele.dk</a>, Sat 12 Dec 1998, 18:58 GMT <UL> <LI><strong><A NAME="00956" HREF="msg00956.html">[MUD-Dev] Re: mud client development systems</A></strong>, Sunny Gulati <a href="mailto:sunnywiz#radiks,net">sunnywiz#radiks,net</a>, Sat 12 Dec 1998, 20:41 GMT <UL> <LI><strong><A NAME="00959" HREF="msg00959.html">[MUD-Dev] Re: mud client development systems</A></strong>, Per Vognsen <a href="mailto:vognsen#post10,tele.dk">vognsen#post10,tele.dk</a>, Sun 13 Dec 1998, 16:25 GMT </LI> </UL> </LI> </UL> </LI> </UL> </LI> <LI><strong><A NAME="00957" HREF="msg00957.html">[MUD-Dev] Re: mud client development systems</A></strong>, Scatter <a href="mailto:scatter#thevortex,com">scatter#thevortex,com</a>, Sat 12 Dec 1998, 23:36 GMT </LI> </ul> </LI> </UL></BLOCKQUOTE> </ul> <hr> <center> [ <a href="../">Other Periods</a> | <a href="../../">Other mailing lists</a> | <a href="/search.php3">Search</a> ] </center> <hr> </body> </html>