<!-- MHonArc v2.4.4 --> <!--X-Subject: SfD: Clientside Caching --> <!--X-From-R13: @nguna T Kbfcr <lbfcrNunjnvv.rqh> --> <!--X-Date: Tue, 17 Mar 1998 01:01:47 +0000 --> <!--X-Message-Id: Pine.GSO.3.95q.980310153234.4069A-100000@uhunix1 --> <!--X-Content-Type: text/plain --> <!--X-Head-End--> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <html> <head> <title>MUD-Dev message, SfD: Clientside Caching</title> <!-- meta name="robots" content="noindex,nofollow" --> <link rev="made" href="mailto:yospe#hawaii,edu"> </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="msg00728.html">Previous</a> | <a href="msg00730.html">Next</a> ] Thread: [ <a href="msg00779.html">Previous</a> | <a href="msg00746.html">Next</a> ] Index: [ <A HREF="author.html#00729">Author</A> | <A HREF="#00729">Date</A> | <A HREF="thread.html#00729">Thread</A> ] <!--X-TopPNI-End--> <!--X-MsgBody--> <!--X-Subject-Header-Begin--> <H1>SfD: Clientside Caching</H1> <HR> <!--X-Subject-Header-End--> <!--X-Head-of-Message--> <UL> <LI><em>To</em>: Mud Design Mailing List <<A HREF="mailto:mud-dev#null,net">mud-dev#null,net</A>></LI> <LI><em>Subject</em>: SfD: Clientside Caching</LI> <LI><em>From</em>: Nathan F Yospe <<A HREF="mailto:yospe#hawaii,edu">yospe#hawaii,edu</A>></LI> <LI><em>Date</em>: Mon, 16 Mar 1998 15:01:15 -1000</LI> <LI><em>Reply-To</em>: Nathan F Yospe <<A HREF="mailto:yospe#hawaii,edu">yospe#hawaii,edu</A>></LI> </UL> <!--X-Head-of-Message-End--> <!--X-Head-Body-Sep-Begin--> <HR> <!--X-Head-Body-Sep-End--> <!--X-Body-of-Message--> <PRE> SfD: Subject for Discussion. I decided to stir things up. It has been slow. I'm going to start posting these every few weeks, or as the impulse strikes me... just to get the juices pumping. Feel free to tear it to pieces. Today's topic: Storage of data for a mud on a permanent or temporary basis. For now, I will assume a system that only works with a custom client, where 'client' means either a remote pure client, or a 'smart' client, like those employed (presumably) by UOL. (Is M59 a pure client? I'm pretty sure Pueblo is.) A little background: Some months ago, I discovered that my prototype concept mud was far more than my hardware could handle. It was built around three distinct processes that I could easilly seperate: a detailed physical simulation, a parser for input commands, and a dynamic text generator. Of the three, the first would have to be handled by the server (or servers, as I have been designing with distributed processing in mind), but the two user interface concerns were a good candidate for a client. After a bit of consideration, I began thinking out the client's design. At this point in time, I have completed a skeletal server, and the most rudimentary server interface of a client. I won't have much opportunity to complete the client in the near future, but I do intend to finish it all eventually. I currently work on it for three hours a week. There were several issues that I considered when deciding to create this client. The first was portability. In the end, I decided to make the client in two forms; the first a Java GUI application with optional native methods for select platforms, the second a Java text application with output to the main terminal, again with optional native methods, to be hosted by the user on some unix account, here effectively giving them a way to play the mud as if it were a regular telnet server, with a telnet client. It may be a hack, but it has a few plusses. Much of the work is done by the player's machine, be it their home PC or the machine they have an account on. The player also supplies the memory space for the larger portion of their character and ego preferences and memories. The second major issue was capability; I couldn't do what I wanted to do without a client on current resources, and I wanted, as a bonus, to be able to provide a GUI and background pictures for clients not running as telnet. I did have one problem here, in running the same set of preferences on multiple machines, for someone who uses several computers each day. I will get into the possible solutions to that when I finish this introduction. The third concern was flexibility, and I admit to having much more difficulty on this issue than the others. This leads to another reason to cache: downloadable updates to the client. The alternative was downloads of the entire client every time I changed something. The fourth issue is an enormous one, and I may have flubbed it: possibility. I may have gotten too wide eyed on this one, but I'm going for it. Readers of rec.games.mud.admin may recognize these criteria... I posted an extensive discussion on it, but there were no replies. *sigh* I'll repost it here, maybe. We need matter to get things going again. (If anyone else wants to start posting SfDs, please do. I don't have any kind of trademark on the name, and random thoughts are good fodder for productive discussion, especially with the brain-pool here. Essentially, the question of client caching comes down to 1) What are we going to cache, 2) How long are we going to cache it for, 3) where and how, and 4) why do we need to cache it? This brings us to the technical portions of this discourse, and I will now try to break my inane habit of right hand justification. It's become an addiction, you see. 1) What are we going to cache? There are several potential candidates for caching. Of course, there are the obvious ones; graphics ought to be cached in memory, then on disk if a disk is available (this is not possible with applets), sounds ought to at the very least be cached on disk; anything else of similar size should, at all costs, be kept as far from repeated downloading as possible. Text, while less bandwidth intensive, might also be a candidate for caching. On the other hand, anything cached is no longer subject to modification by the server unless update flags exist. A client could potentially cache even the behavior of objects, if said behavior was controlled by some non binary algorithms; but in this case, there would have to be some sort of regular conformation checking with the server. A good basis for the answer to the above question, then, is, 'how much can we safely offload onto the client?' The client can obviously be trusted to store anything that would be sent once, as there is no longer any security concerns with that information. If there is a concern about the player hacking the client to provide more than the information a player ought to have, the data storable drops dramaticly. However, some discretion in how the data is stored - non sequential storage relative to physical location; storing text in a database with tokenized references to word sequences, perhaps even a dictionary/thesaurus approach with some form of abstracted linguistic association (guess what I've been up to yet?)... or in the case of graphics, storage in a pallette based table, which saves you in space, and results in a scrambling of data that can't be easily sorted before the subjects of the graphics (assuming some form of flate sprite graphics) or a similarly stored polygon library... the only other option is to be extremely paranoid about what you allow a client to see. Remember, a hacker can store anything you send; this is not an issue of the client. If you don't want it stored, don't send it. Period. If you want it stored, but not readable without great effort, my advise is to send it in big chunks of database material and extract it by some method that is integral to the client and well disguised, or, alternatively, under the direction of the server. This covers well the storage of things from the server, but there is another potential here that I think is far more valuable: storage of those things inherent to the client's "memory"... be it name recognition, scripts and preferences, or a complete "personality" to be applied to text parsing or generation, having this on the client's end opens up a whole new level of potential. This is currently embodied by arcade fighting and racing games. Have you ever seen one of these games get tougher and "smarter"? To recap: We can cache three basic types of data; transient data from the server, database contents from the server, and 'memory' data from the player. Which ones we cache, and how much of each, depends on the specific case in question. 2. How Long are we going to Cache it for? We've got a chunk of data; we want to be able to reference it without downloading it again; but we don't want to store it forever - unless we are doing the database thing, in which case we may go so far as releasing most of it on a CD and just storing updates (ref. UOL, M59?), or at the very least, notifying clients that the database may reach a size as large as X, where X is some number larger than what (you hope) is the maximum size in the reasonably foreseeable future. I specify 1, 2, 4, 10, and 20 MB caches at the moment; each has a slightly different characteristic; text only mode may go as large as 15 MB, and the graphical backdrop mode also features a 50 MB cache option in spite of my relatively well compressed backdrops; it should handle anything I ever produce, but I haven't figured out how I'm going to ever make that mondo chunk available for download.) So, we've got this data, we need to weed out the junk and keep the good stuff; otherwise, how are we going to store it all? Well, first of all, can we compress it at all? And what about duplicate information? Is there any? OK, we've gotten rid of all the duplication, compressed... we still have too much cached data. What now? Now, we decide what we make our criteria for dumping stuff. Age? Infrequent use? No recent use? Size? This one goes both ways; the stuff that saves you the most space costs the most to get again. Generally, small infrequently (or unrecently) used stuff is the best candidate. Small stuff adds up, and you have more time to get it back, if you download as needed. Or rather, you require less time at the point where the need occurs. On the other hand, if you can download stuff in the background, the big stuff comes down faster, megabyte for megabyte. This is generally associated with large scale storage models, however. What if we've got stuff in memory cache, and want to clear that out? Is it better to save it to disk than to redownload it? Obviously, over a modem it would be, but sometimes it is faster on the client side to get it over a T1 connection than to load it from disk. This is one of the points where I tend to say, "Server first!". Even if a specific case happens to have the bandwidth to grab stuff fast, and slow disk access, a few dozen of these will kill the server. The server should always be primary concern, the user should be asked to bear as much of the burden as possible. 3) Where and How? This is not just a question of memory, disk, or register. This is also one of access... if we are caching for the convenience of the client and server on downloads, we want it right there, but say there is a memory of some sort associated with the client. Does a player who uses many machines have to carry their memories on a disk? Why not allow a player to set some remote accessable point, in the manner of a remote .newsrc, that can be pointed to by multiple machines, with a breakpoint on time, or a SCCSlike diff function? This is a different sort of caching, with different motives and methods, but it has some serious implications as well. 4) why do we need to cache it? Always make the client do the lion's share of the work. Others may disagree, but this philosophy has served me well... just think of it this way: a hundred users, with a few of them using straining 286s and Mac IIs, and a server (or distributed network of servers, but I'm figuring upward of 100 clients per server) pushing itself to handle the simulation end; VS a much less capable server, and a bunch of dumb clients totally failing to burn any of the users' processing capabilities. Now, I will admit that a mud as we know it now barely taxes a modern Pentium X or PPC chip, but... just think how much more that mud could do if the text parsing and so forth were handled by the clients, leaving the server to do the simulation. This is the real promise of clientside caching. My client even handles the line- of-sight calculations, which may be a bad idea - how hard is that going to be to hack, and how long until people release the first "around the corner" cheat? - but saves yet another major calculation for me. I always hated to do the ray tracing; spherical resolution collision detection is bad enough. Generally, the reasons covered above... memory for the client, reduced download time, and reduced work for the data server (I have a data and an event server. This may well make up the core of a future TfD.), with some additional emphasis on tricks like dynamic text generation, more flexible namespace storage, and so forth, cover the majority of cases. I'm sure you all have others. Let's here some feedback! -- Nathan F. Yospe - Aimed High, Crashed Hard, In the Hanger, Back Flying Soon Jr Software Engineer, Textron Systems Division (On loan to Rocketdyne Tech) (Temporarily on Hold) Student, University of Hawaii at Manoa, Physics Dept. yospe#hawaii.edu nyospe#premier.mhpcc.af.mil <A HREF="http://www2.hawaii.edu/~yospe/">http://www2.hawaii.edu/~yospe/</A> </PRE> <!--X-Body-of-Message-End--> <!--X-MsgBody-End--> <!--X-Follow-Ups--> <HR> <ul compact><li><strong>Follow-Ups</strong>: <ul> <li><strong><A NAME="00746" HREF="msg00746.html">Re: [MUD-Dev] SfD: Clientside Caching</A></strong> <ul compact><li><em>From:</em> "Jon A. Lambert" <jlsysinc#ix,netcom.com></li></ul> </UL></LI></UL> <!--X-Follow-Ups-End--> <!--X-References--> <!--X-References-End--> <!--X-BotPNI--> <UL> <LI>Prev by Date: <STRONG><A HREF="msg00728.html">RE: [MUD-Dev] Balancing Addicts -> soft vs. hard enforcement</A></STRONG> </LI> <LI>Next by Date: <STRONG><A HREF="msg00730.html">Re: [MUD-Dev] Magic as Metaphor</A></STRONG> </LI> <LI>Prev by thread: <STRONG><A HREF="msg00779.html">Re: [MUD-Dev] Transport layer (UDP vs TCP)</A></STRONG> </LI> <LI>Next by thread: <STRONG><A HREF="msg00746.html">Re: [MUD-Dev] SfD: Clientside Caching</A></STRONG> </LI> <LI>Index(es): <UL> <LI><A HREF="index.html#00729"><STRONG>Date</STRONG></A></LI> <LI><A HREF="thread.html#00729"><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>Re: [MUD-Dev] Transport layer (UDP vs TCP)</STRONG>, <EM>(continued)</EM> <ul compact> <ul compact> <ul compact> <ul compact> <ul compact> <LI><strong><A NAME="00758" HREF="msg00758.html">Re: [MUD-Dev] Transport layer (UDP vs TCP)</A></strong>, Ben Greear <a href="mailto:greear#cyberhighway,net">greear#cyberhighway,net</a>, Thu 19 Mar 1998, 00:52 GMT <UL> <LI><strong><A NAME="00763" HREF="msg00763.html">Re: [MUD-Dev] Transport layer (UDP vs TCP)</A></strong>, Niklas Elmqvist <a href="mailto:d97elm#dtek,chalmers.se">d97elm#dtek,chalmers.se</a>, Thu 19 Mar 1998, 08:18 GMT </LI> <LI><strong><A NAME="00778" HREF="msg00778.html">Re: [MUD-Dev] Transport layer (UDP vs TCP)</A></strong>, Jon A. Lambert <a href="mailto:jlsysinc#ix,netcom.com">jlsysinc#ix,netcom.com</a>, Fri 20 Mar 1998, 03:06 GMT <UL> <LI><strong><A NAME="00779" HREF="msg00779.html">Re: [MUD-Dev] Transport layer (UDP vs TCP)</A></strong>, Ben Greear <a href="mailto:greear#cyberhighway,net">greear#cyberhighway,net</a>, Fri 20 Mar 1998, 04:28 GMT </LI> </UL> </LI> </UL> </LI> </ul> </ul> </ul> </ul> </ul> </LI> <LI><strong><A NAME="00729" HREF="msg00729.html">SfD: Clientside Caching</A></strong>, Nathan F Yospe <a href="mailto:yospe#hawaii,edu">yospe#hawaii,edu</a>, Tue 17 Mar 1998, 01:01 GMT <UL> <LI><strong><A NAME="00746" HREF="msg00746.html">Re: [MUD-Dev] SfD: Clientside Caching</A></strong>, Jon A. Lambert <a href="mailto:jlsysinc#ix,netcom.com">jlsysinc#ix,netcom.com</a>, Wed 18 Mar 1998, 06:05 GMT <UL> <LI><strong><A NAME="00755" HREF="msg00755.html">Re: [MUD-Dev] SfD: Clientside Caching</A></strong>, Nathan F Yospe <a href="mailto:yospe#hawaii,edu">yospe#hawaii,edu</a>, Wed 18 Mar 1998, 23:18 GMT <UL> <LI><strong><A NAME="00761" HREF="msg00761.html">Re: [MUD-Dev] SfD: Clientside Caching</A></strong>, Jon A. Lambert <a href="mailto:jlsysinc#ix,netcom.com">jlsysinc#ix,netcom.com</a>, Thu 19 Mar 1998, 06:51 GMT </LI> </UL> </LI> </UL> </LI> </UL> </LI> <LI><strong><A NAME="00720" HREF="msg00720.html">RE: [MUD-Dev] (no title) Time limits?</A></strong>, Justin McKinnerney <a href="mailto:xymox#toon,org">xymox#toon,org</a>, Sun 15 Mar 1998, 23:35 GMT </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>