<!-- MHonArc v2.4.4 --> <!--X-Subject: [MUD-Dev] distributed, _untrusted_ servers --> <!--X-From-R13: Ayvire Xbjrgg <vprphorNvuht.pb.am> --> <!--X-Date: Fri, 12 Mar 1999 05:45:21 -0800 --> <!--X-Message-Id: Pine.LNX.3.96.990312095616.392C-100000#agrajag,internal --> <!--X-Content-Type: text/plain --> <!--X-Head-End--> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <html> <head> <title>MUD-Dev message, [MUD-Dev] distributed, _untrusted_ servers</title> <!-- meta name="robots" content="noindex,nofollow" --> <link rev="made" href="mailto:icecube#ihug,co.nz"> </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="msg00550.html">Previous</a> | <a href="msg00552.html">Next</a> ] Thread: [ <a href="msg00606.html">Previous</a> | <a href="msg00547.html">Next</a> ] Index: [ <A HREF="author.html#00551">Author</A> | <A HREF="#00551">Date</A> | <A HREF="thread.html#00551">Thread</A> ] <!--X-TopPNI-End--> <!--X-MsgBody--> <!--X-Subject-Header-Begin--> <H1>[MUD-Dev] distributed, _untrusted_ servers</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] distributed, _untrusted_ servers</LI> <LI><em>From</em>: Oliver Jowett <<A HREF="mailto:icecube#ihug,co.nz">icecube#ihug,co.nz</A>></LI> <LI><em>Date</em>: Sat, 13 Mar 1999 02:44:55 +1300 (NZDT)</LI> <LI><em>Reply-To</em>: <A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A></LI> <LI><em>Sender</em>: <A HREF="mailto:mud-dev-admin#kanga,nu">mud-dev-admin#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> Something I've been thinking about recently, somewhat related to the current load-balancing etc discussion: supporting "leaf" servers that support groups of nearby clients and keep the bandwidth/latency needed to the main game server down. The catch is that I want _users_ to run these leaf servers - so they're "in the hands of the enemy".. This is really aimed at systems where the client protocol deals in terms of game objects not raw text - in mud terms, more along the lines of a graphical mud I suppose. I started on a long detailed description of it but it became incomprehensible at about line 200 :) so here's the cut-down version: -- Topology: central, trusted, server or servers that maintain the official game state. Clients can connect directly to these servers. Leaf servers, not trusted, can also connect. Clients may connect to a nearby leaf server that they trust instead of going direct to the central servers. Ideally I'd like a situation where it's possible to hang 20-30 clients on a LAN off a leaf server, and have that leaf server connect over a slow link (modem etc) to the central server(s) - and have the game remain playable. Clients connect to the leaf server and authenticate; the leaf server just acts as a proxy, forwarding the authentication to the central servers. The leaf server then gets sent all directly-visible information that its clients can see (i.e. we're not giving out more info than we'd give each client if it connected directly). Game data is classified into three categories: . local - all details are known by the leaf server, and the leaf server can assume the central server won't be unexpectedly modifying these details . remote - some or all details are only known by the central servers . dangerous - not really a type of data, but a set of states where "local" data might change unknown to the leaf server. "remote" data will initially include everything about the gameworld that the clients don't automatically have access to. "dangerous" data is hard to explain clearly, but in essense it defines the region of the game where the leaf server can be sure that it has all the data it needs - and that another client connected elsewhere won't interfere with it. For example, it would include a description of the parts of the game map where there's no chance of another client modifying. Defining dangerous data could get very complex, but it can be cut down by noting that the only data that is potentially dangerous is data that can be local, and then only making data that is performance-critical potentially local. Over time the set of dangerous data changes as events occur elsewhere in the gameworld - the central server will regularly update the leaf server with new dangerous regions. --- How client requests are handled depends on what type of data they involve: . If all data is local, the leaf server immediately performs the request. If the request has an effect on the game-world (i.e. it's not invalid or an information-request-only request) then it is also echoed to the central server. . If any data referred to is remote, the appropriate bits of the request are forwarded to the central server and the response is _waited for_. After each request (? - or just regularly?) the state of the data involved is updated. Possibly remote data might change to being local - for example, identifying an item must be remote to avoid leaf servers just extracting the information directly without paying the in-game cost, but once identified the item information might as well be local (assuming there's no other reason for it to be remote). If data has moved into a dangerous state it becomes remote (for example, moving into a region near another client not handled by the leaf server) The central server will be regularly firing updates to the data that the leaf server has as the game world changes, as well. The degenerate case is where there is a lot of activity going on in a particular area, no data is local to the leaf server, and everything goes through the central servers to maintain consistency. In the "ideal" case, where you have no interaction between the leaf server's clients and other clients, the leaf server should just be sending information on what its clients are doing to the central server (to update the overall game state), plus the occasional request that has to be performed on the central servers itself. -- Did that make _any_ sense to anyone? I know it's not very clear, but I'm interested in feedback. -- Oliver Jowett - icecube#ihug,co.nz - <A HREF="http://homepages.ihug.co.nz/~icecube/">http://homepages.ihug.co.nz/~icecube/</A> KeyID: 1024/679D94C5 Fingerprint: CD94 5270 E2F4 339F 6A90 05C9 9DE4 EECC _______________________________________________ MUD-Dev maillist - MUD-Dev#kanga,nu <A HREF="http://www.kanga.nu/lists/listinfo/mud-dev">http://www.kanga.nu/lists/listinfo/mud-dev</A> </PRE> <!--X-Body-of-Message-End--> <!--X-MsgBody-End--> <!--X-Follow-Ups--> <HR> <!--X-Follow-Ups-End--> <!--X-References--> <!--X-References-End--> <!--X-BotPNI--> <UL> <LI>Prev by Date: <STRONG><A HREF="msg00550.html">Re: [MUD-Dev] Naming and Directories?</A></STRONG> </LI> <LI>Next by Date: <STRONG><A HREF="msg00552.html">RE: [MUD-Dev] How to support 1000+ simultaneous connections, and some philosophy.</A></STRONG> </LI> <LI>Prev by thread: <STRONG><A HREF="msg00606.html">Re: [MUD-Dev] Elder Games</A></STRONG> </LI> <LI>Next by thread: <STRONG><A HREF="msg00547.html">[MUD-Dev] Naming and Directories?</A></STRONG> </LI> <LI>Index(es): <UL> <LI><A HREF="index.html#00551"><STRONG>Date</STRONG></A></LI> <LI><A HREF="thread.html#00551"><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] Elder Games</STRONG>, <EM>(continued)</EM> <ul compact> <ul compact> <LI><strong><A NAME="00604" HREF="msg00604.html">Re: [MUD-Dev] Elder Games</A></strong>, J C Lawrence <a href="mailto:claw#varesearch,com">claw#varesearch,com</a>, Tue 16 Mar 1999, 10:16 GMT </LI> <LI><strong><A NAME="00617" HREF="msg00617.html">Re: [MUD-Dev] Elder Games</A></strong>, Nathan F Yospe <a href="mailto:yospe#hawaii,edu">yospe#hawaii,edu</a>, Tue 16 Mar 1999, 16:14 GMT <UL> <LI><strong><A NAME="00643" HREF="msg00643.html">Re: [MUD-Dev] Elder Games</A></strong>, J C Lawrence <a href="mailto:claw#kanga,nu">claw#kanga,nu</a>, Wed 17 Mar 1999, 22:33 GMT </LI> </UL> </LI> </ul> <LI><strong><A NAME="00606" HREF="msg00606.html">Re: [MUD-Dev] Elder Games</A></strong>, Benjamin D. Wiechel <a href="mailto:strycher#toast,net">strycher#toast,net</a>, Tue 16 Mar 1999, 12:14 GMT </LI> </ul> </LI> <LI><strong><A NAME="00551" HREF="msg00551.html">[MUD-Dev] distributed, _untrusted_ servers</A></strong>, Oliver Jowett <a href="mailto:icecube#ihug,co.nz">icecube#ihug,co.nz</a>, Fri 12 Mar 1999, 13:45 GMT <LI><strong><A NAME="00547" HREF="msg00547.html">[MUD-Dev] Naming and Directories?</A></strong>, Mark Gritter <a href="mailto:mark#erdos,Stanford.EDU">mark#erdos,Stanford.EDU</a>, Fri 12 Mar 1999, 07:44 GMT <UL> <LI><strong><A NAME="00548" HREF="msg00548.html">Re: [MUD-Dev] Naming and Directories?</A></strong>, Matthew D. Fuller <a href="mailto:fullermd#futuresouth,com">fullermd#futuresouth,com</a>, Fri 12 Mar 1999, 11:04 GMT <UL> <LI><strong><A NAME="00569" HREF="msg00569.html">Re: [MUD-Dev] Naming and Directories?</A></strong>, Adam Wiggins <a href="mailto:adam#angel,com">adam#angel,com</a>, Sat 13 Mar 1999, 14:13 GMT </LI> </UL> </LI> <LI><strong><A NAME="00550" HREF="msg00550.html">Re: [MUD-Dev] Naming and Directories?</A></strong>, Hans-Henrik Staerfeldt <a href="mailto:hhs#cbs,dtu.dk">hhs#cbs,dtu.dk</a>, Fri 12 Mar 1999, 12:56 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>