<!-- MHonArc v2.4.4 -->
<!--X-Subject: RE: [MUD-Dev] Languages for MUD drivers -->
<!--X-From-R13: Qlaor eh Fnera <plaorNzhd.bet> -->
<!--X-Date: Thu, 18 Nov 1999 09:01:01 -0800 -->
<!--X-Message-Id: 199911180758.BAA18704#laurel,actlab.utexas.edu -->
<!--X-Content-Type: text/plain -->
<!--X-Head-End-->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<title>MUD-Dev message, RE: [MUD-Dev] Languages for MUD drivers</title>
<!-- meta name="robots" content="noindex,nofollow" -->
<link rev="made" href="mailto:cynbe#muq,org">
</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="msg00363.html">Previous</a>
| <a href="msg00356.html">Next</a>
]
Thread:
[ <a href="msg00354.html">Previous</a>
| <a href="msg00256.html">Next</a>
]
Index:
[ <A HREF="author.html#00361">Author</A>
| <A HREF="#00361">Date</A>
| <A HREF="thread.html#00361">Thread</A>
]
<!--X-TopPNI-End-->
<!--X-MsgBody-->
<!--X-Subject-Header-Begin-->
<H1>RE: [MUD-Dev] Languages for MUD drivers</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>: RE: [MUD-Dev] Languages for MUD drivers</LI>
<LI><em>From</em>: Cynbe ru Taren <<A HREF="mailto:cynbe#muq,org">cynbe#muq,org</A>></LI>
<LI><em>Date</em>: Thu, 18 Nov 1999 01:58:31 -0600</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>
"Ian Macintosh" <iman#issystems,co.nz> comments:
| The reason why I believe this is better than using RPC or whatever to
| load balance based on events, is that I can't get away from the
| requirement that one system has to be the master, or own, a particular
| piece of the MUD.
|
| i.e., Server B handles Midgaard, and as such, if *anyone* or *any
| server* wants to know the exact state of Market Square, it must find
| out here. If there are two servers possibly handling the same piece
| of real estate, who's version is the right one? Likewise, Server E
| controls the Grand Mistress of Magic sitting on her throne in the High
| Tower of Sorcery. If you want to know her status, you find that out
| by querying Server E.
I've spent a fair amount of time thinking about (and coding!) such
stuff, and I fairly strongly agree that one definitive server owner
per given bit of state is the practical solution: The distributed db
people can offer alternatives, but imho they will prove too
heavyweight and too vulnerable to malicious denial of service attacks
to be effective in our sort of setting.
There are however lots of tricks which can be applied to reduce
hotspot problems, including:
* Marking state as read-only where-ever appropriate. Read-only
state can be widely cached and circulated between remote
servers, reducing hotspot server load. This may require
something like public-key signatures on such state to guarantee
authenticity, hashcode names to identify parts of it, and a
server-server protocol for enquiring if a given bit of state
happens to be in cache, please.
* Even where state is not actually read-only, it may be possible
to mark it as cache-able for a period of minutes, hours or
days: This is basically the critical trick that makes DNS
a practical engineer proposition instead of a cute theoretical
idea. Background descriptions (explicit or procedural) which
get updated infrequently are reasonable candidates for this,
and may easily constitute most of the state of many systems.
Beyond the addition of the timeout, the implementation
hacks are the same as for read-only state.
* Broadcast protocols can be used to make the load on a server
independent of the number of clients. Formal network broadcast
facilities like MBONE can be cool in this context if available,
but similar effects can be achieved by assembling clients into
fanout trees: Making the hotspot clients part of the load
solution, not just part of the problem. If this is done well,
it effectively means that server hardware sources automatically
scale to meet the load, since each client contributes resources
to the server.
None of which constitute a magic bullet making all the problems
go away -- but since when does any kind of engineering work that
way anyhow? :)
Cynbe
_______________________________________________
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="msg00363.html">Re: [MUD-Dev] Mud hosting services</A></STRONG>
</LI>
<LI>Next by Date:
<STRONG><A HREF="msg00356.html">Re: [MUD-Dev] code base inquiry</A></STRONG>
</LI>
<LI>Prev by thread:
<STRONG><A HREF="msg00354.html">Re: [MUD-Dev] Languages for MUD drivers</A></STRONG>
</LI>
<LI>Next by thread:
<STRONG><A HREF="msg00256.html">[MUD-Dev] code base inquiry</A></STRONG>
</LI>
<LI>Index(es):
<UL>
<LI><A HREF="index.html#00361"><STRONG>Date</STRONG></A></LI>
<LI><A HREF="thread.html#00361"><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] Languages for MUD drivers</STRONG>, <EM>(continued)</EM>
<ul compact>
<LI><strong><A NAME="00317" HREF="msg00317.html">Re: [MUD-Dev] Languages for MUD drivers</A></strong>,
Laurent Bossavit <a href="mailto:laurent#netdive,com">laurent#netdive,com</a>, Wed 17 Nov 1999, 23:19 GMT
</LI>
<LI><strong><A NAME="00351" HREF="msg00351.html">Re: [MUD-Dev] Languages for MUD drivers</A></strong>,
Cynbe ru Taren <a href="mailto:cynbe#muq,org">cynbe#muq,org</a>, Thu 18 Nov 1999, 07:34 GMT
</LI>
<LI><strong><A NAME="00344" HREF="msg00344.html">RE: [MUD-Dev] Languages for MUD drivers</A></strong>,
Cynbe ru Taren <a href="mailto:cynbe#muq,org">cynbe#muq,org</a>, Thu 18 Nov 1999, 07:34 GMT
</LI>
<LI><strong><A NAME="00354" HREF="msg00354.html">Re: [MUD-Dev] Languages for MUD drivers</A></strong>,
Cynbe ru Taren <a href="mailto:cynbe#muq,org">cynbe#muq,org</a>, Thu 18 Nov 1999, 07:44 GMT
</LI>
<LI><strong><A NAME="00361" HREF="msg00361.html">RE: [MUD-Dev] Languages for MUD drivers</A></strong>,
Cynbe ru Taren <a href="mailto:cynbe#muq,org">cynbe#muq,org</a>, Thu 18 Nov 1999, 17:01 GMT
</LI>
</ul>
</LI>
<LI><strong><A NAME="00256" HREF="msg00256.html">[MUD-Dev] code base inquiry</A></strong>,
Ilya, Game Commandos <a href="mailto:Ilya#gamecommandos,com">Ilya#gamecommandos,com</a>, Tue 16 Nov 1999, 01:19 GMT
<UL>
<LI><strong><A NAME="00278" HREF="msg00278.html">Re: [MUD-Dev] code base inquiry</A></strong>,
Lars Duening <a href="mailto:lars#bearnip,com">lars#bearnip,com</a>, Wed 17 Nov 1999, 02:18 GMT
<UL>
<LI><strong><A NAME="00285" HREF="msg00285.html">Re: [MUD-Dev] code base inquiry</A></strong>,
Travis S. Casey <a href="mailto:efindel#io,com">efindel#io,com</a>, Wed 17 Nov 1999, 16:31 GMT
<UL>
<LI><strong><A NAME="00301" HREF="msg00301.html">Re: [MUD-Dev] code base inquiry</A></strong>,
Andru Luvisi <a href="mailto:luvisi#andru,sonoma.edu">luvisi#andru,sonoma.edu</a>, Wed 17 Nov 1999, 21:24 GMT
</LI>
</UL>
</LI>
</UL>
</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>