<!-- MHonArc v2.4.4 --> <!--X-Subject: Re: [MUD-Dev] Languages for MUD drivers --> <!--X-From-R13: X Q Znjerapr <pynjNpc.arg> --> <!--X-Date: Fri, 19 Nov 1999 15:37:41 -0800 --> <!--X-Message-Id: E11oxb0-0005pV-00#under,eng.cp.net --> <!--X-Content-Type: text/plain --> <!--X-Reference: E11nY0E-0006Ai-00#kanga,nu --> <!--X-Reference: E11oCVu-0003m8-00#kanga,nu --> <!--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:claw#cp,net"> </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="msg00410.html">Previous</a> | <a href="msg00414.html">Next</a> ] Thread: [ <a href="msg00350.html">Previous</a> | <a href="msg00412.html">Next</a> ] Index: [ <A HREF="author.html#00411">Author</A> | <A HREF="#00411">Date</A> | <A HREF="thread.html#00411">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>: J C Lawrence <<A HREF="mailto:claw#cp,net">claw#cp,net</A>></LI> <LI><em>Date</em>: Fri, 19 Nov 1999 15:37:38 -0800</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> On Wed, 17 Nov 1999 22:13:44 +0100 Laurent Bossavit <bossavit#cybercable,fr> wrote: > There's no really good (read transparent) way to interconnect > several MOO servers in that way. Suppose I'm running the Feral > Forest on server A, the Damp Dungeon on server B; I want the key > from the lower dungeon cell to open the witch's hut in the forest > - hence I want the player to be able to take the key and move from > A to B, moving the key with em - and there's no way AFAIK that can > be done with MOO. CoolMUD implements a simple object RPC protocol called "YO" which can work for this, given that the interconnect between the servers is both fast and of low latency: --<cut>-- COOLMUD is distributed in a different way than other "distributed" systems such as UnterMUD. Instead of providing a method of sending objects from database to database, COOLMUD allows you to define a suite of messages which may be passed between objects. The YO protocol and the COOLMUD database define the suite of messages for a particular implementation. For example, symbolically, a typical exchange between objects might be: object A object B -------- -------- - what is your location? - my location is ... - move yourself to ... - ok Objects don't actually move from machine to machine; they simply update their location and contents fields to move around. The object remains on the server it was created on; its location field simply 'points' to the object representing its new location. This means that anything which may be done with a local object can be done with a remote object. Thus, you may program a fancy object on your local mud, carry it to a remote mud, and all the functionality comes along with it. There are two major limitations in COOLMUD: 1) Inheritance may not span MUDs. The parent of an object must reside on the same MUD as the child object. This is done to reduce network traffic to an acceptable level, and to simplify the message passing system. 2) To program an object, both the player and the object being programmed must reside on the same server. This also reduces net traffic, since the COOL code only has go across one link (that between a player and the local MUD). --<cut>-- and: --<cut>-- The YO (Yell at Object) protocol defines the format and content of messages that may be passed between severs on a distributed MUD. It does not ferry objects around, as the OIF protocol does, but instead defines the messages that may be passed between objects. COOLMUD users and programmers do not need to know the YO protocol to program or use COOLMUD. This document is intended for people who want to know the internals of the COOLMUD system. YO packets consist of 7 parts: the message id, age, player object, from object, to object, message, and arguments. Any object can send any other object a message, but it must be directed to the appropriate server. Any messages which do not conform to this format may be silently discarded. Here's a dissection of a typical YO packet: 3245 0 #3@joemud #7@joemud #9@fredmud "tell" { 1 "howdy" } ^ ^ ^ ^ ^ ^ ^ | | | | | | | msgid age player from to msg args --<cut>-- You can find the relevent docs and source files in the CoolMUD archives on ftp.kanga.nu, or at Stephen White's university site. > Even assuming something like an 'object exchange protocol' that > would let server A open a connection to server B, spit out the key > object's code and properties so that a new, equivalent object can > be created there, and the old key deleted; assuming I have a way > to make sure the key won't be duplicated or deleted altogether if > something happens to the network connection between A and B while > this is going on; assuming I can do the same to the player object; > assuming I can require the player emself to disconnect from A and > reconnect to B in an orderly fashion whenever this happens - which > implies a custom client program, or tech support headaches... Object migration between hosts is not a trivial problem, but it is also a problem that is well known and has significant prior art. I'm being remarkably unsuccessful in finding that prior art right now, but that could have something to do with the fact that I'm quite hungry and not looking forward to the three block walk thru the rain to a foodery. The "OIP Porotocol" referenced above appears to refer to work done by the OIP group in regard to Java/Corba translations: <A HREF="http://www.mcc.com/projects/oip/">http://www.mcc.com/projects/oip/</A> <A HREF="http://www.mcc.com/projects/oip/papers/paper067.htm">http://www.mcc.com/projects/oip/papers/paper067.htm</A> I don't see a whole lot of direct use (for us) there. > Hmm, I can't assume all of the above anyway since it's far from > realistic, but you see where this would lead - a lot of in-DB code > that deals only with such interconnections. (And what if the key > has a property pointing to another object local to A; and what if > the key has parent objects that are not in B, etc. etc.) It's much > better if such distributed processing is in some appropriate > fashion a capability of the server itself. MOO as it is doesn't > fit the bill; and adding these capabilities to a MOO server > wouldn't be a piece of cake. My assertions: -- persistance should be an innate and invisible (not just transparent) property of the programming environment. Translation; Everything is persistant. Always. -- distribution should be an innate and invisible property of the programming environment. Translation: There is no innate difference between a local object and a remote object other than responsiveness. -- the user, be it programmer or player, should never need to be, or be aware of how the system handles runtime object heirarchy changes other than the mere fact that "it happens" and that they don't need to care about it. Translation: You just write or use code and the system takes care of the rest and always does the right thing. -- the user programmer shoul be able to behave and program as if he were the only user on the system, that the system in fact was solely dedicated to him and no other users or processes necessarily existed, and he had compleat and total access to all resources without adversely affecting the server's operation, performance, or game-world operation. Translations: race conditions, data locking, deadlocks, etc are all non-existent terms within the programming or user environment. -- inter-ibject security should be an understandable fact that can be drawn and in less than 10 seconds on a restaurant napkin, not a bolt-on mishmash of alter-cases some arbitrary interpretation of which happens to be what the server might do (pet peeve). Transaltion: Not ACL's. Not Uber. Not Tiny. Not MOO. Not LPC. -- any feature must be programmable on any object without source access to any other object(s). This is actually one of the toughest constraints of the above set. Translation: You must be able to rewrite an object's behaviour without changing the source for that object. I've been looking into Arjuna's and YOODA's distributed data archictecture for the data handling side. I'm not entirely fond of either as they expose various aspects of the distribution model to the user. > In fact, my port to Java did include distributed operation > support, based on RMI. One of the first things that became > apparent as I was implementing it was that some MOO-language > modifications would be necessary; the very least I could get away > with was a syntactic representation of remote objects, i.e. the > literal #1 referred to the local #1 whereas #my.server.com:1 > referred to #1 on my.server.com. With these modifications it was > possible to call verbs and read or write properties on remote > objects transparently, as if they were local. Very Yo-like. >> I'm not sure of what you are refering to when you say concurrent >> processing support? I understand the term, but I don't >> understand the context re reactive worlds? > I'm basically referring to support for preemptive (rather than > MOO's collaborative) multitasking. Task scheduling seems to be a > primary cause of lag in MOO servers - true multithreading means a > server is more responsive; at least that's the theory. You might like to hit the archvies to see Lambert's and rather different approaches to this. I use a lockless DB model with competitive multi-threading built using rollbacks atop an ACID DB. Lambert uses a variously intelligent look-ahead locking schema that attempts to pre-emptively predict and route around lock conditions. > This is a central feature, at least IMHO, of a modern M* server - > because it lets you write in-DB editors. This may seem peripheral > to some, but it's crucial to the notion of a virtual reality : the > point of MUDs and MOOs was that they could be modified 'from the > inside', which made them more like the real world - we don't 'step > outside' the real world when we want to modify it, but modify it > we do ! Well said sir. -- J C Lawrence Internet: claw#kanga,nu ----------(*) Internet: coder#kanga,nu ...Honorary Member of Clan McFud -- Teamer's Avenging Monolith... _______________________________________________ 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> <ul compact><li><strong>Follow-Ups</strong>: <ul> <li><strong><A NAME="00412" HREF="msg00412.html">Re: [MUD-Dev] Languages for MUD drivers</A></strong> <ul compact><li><em>From:</em> "Laurent Bossavit" <bossavit#cybercable,fr></li></ul> </UL></LI></UL> <!--X-Follow-Ups-End--> <!--X-References--> <UL><LI><STRONG>References</STRONG>: <UL> <LI><STRONG><A NAME="00259" HREF="msg00259.html">[MUD-Dev] Languages for MUD drivers</A></STRONG> <UL><LI><EM>From:</EM> "Laurent Bossavit" <laurent#netdive,com></LI></UL></LI> <LI><STRONG><A NAME="00308" HREF="msg00308.html">RE: [MUD-Dev] Languages for MUD drivers</A></STRONG> <UL><LI><EM>From:</EM> "Laurent Bossavit" <bossavit#cybercable,fr></LI></UL></LI> </UL></LI></UL> <!--X-References-End--> <!--X-BotPNI--> <UL> <LI>Prev by Date: <STRONG><A HREF="msg00410.html">Re: [MUD-Dev] Mud hosting services</A></STRONG> </LI> <LI>Next by Date: <STRONG><A HREF="msg00414.html">Re: [MUD-Dev] about MOO</A></STRONG> </LI> <LI>Prev by thread: <STRONG><A HREF="msg00350.html">RE: [MUD-Dev] Languages for MUD drivers</A></STRONG> </LI> <LI>Next by thread: <STRONG><A HREF="msg00412.html">Re: [MUD-Dev] Languages for MUD drivers</A></STRONG> </LI> <LI>Index(es): <UL> <LI><A HREF="index.html#00411"><STRONG>Date</STRONG></A></LI> <LI><A HREF="thread.html#00411"><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> <ul compact> <ul compact> <ul compact> <LI><strong><A NAME="00416" HREF="msg00416.html">Re: [MUD-Dev] Languages for MUD drivers</A></strong>, J C Lawrence <a href="mailto:claw#cp,net">claw#cp,net</a>, Sat 20 Nov 1999, 01:01 GMT </LI> </ul> <LI><strong><A NAME="00388" HREF="msg00388.html">Re: [MUD-Dev] Languages for MUD drivers</A></strong>, J C Lawrence <a href="mailto:claw#cp,net">claw#cp,net</a>, Fri 19 Nov 1999, 00:30 GMT </LI> </ul> <LI><strong><A NAME="00308" HREF="msg00308.html">RE: [MUD-Dev] Languages for MUD drivers</A></strong>, Laurent Bossavit <a href="mailto:bossavit#cybercable,fr">bossavit#cybercable,fr</a>, Wed 17 Nov 1999, 21:25 GMT <UL> <LI><strong><A NAME="00350" HREF="msg00350.html">RE: [MUD-Dev] Languages for MUD drivers</A></strong>, Ian Macintosh <a href="mailto:iman#issystems,co.nz">iman#issystems,co.nz</a>, Thu 18 Nov 1999, 07:34 GMT </LI> <LI><strong><A NAME="00411" HREF="msg00411.html">Re: [MUD-Dev] Languages for MUD drivers</A></strong>, J C Lawrence <a href="mailto:claw#cp,net">claw#cp,net</a>, Fri 19 Nov 1999, 23:37 GMT <UL> <LI><strong><A NAME="00412" HREF="msg00412.html">Re: [MUD-Dev] Languages for MUD drivers</A></strong>, Laurent Bossavit <a href="mailto:bossavit#cybercable,fr">bossavit#cybercable,fr</a>, Sat 20 Nov 1999, 00:39 GMT </LI> </UL> </LI> </UL> </LI> </ul> <LI><strong><A NAME="00334" HREF="msg00334.html">Re: [MUD-Dev] Languages for MUD drivers</A></strong>, J C Lawrence <a href="mailto:claw#cp,net">claw#cp,net</a>, Thu 18 Nov 1999, 01:30 GMT </LI> <LI><strong><A NAME="00347" HREF="msg00347.html">[MUD-Dev] Languages for MUD drivers</A></strong>, Petri Virkkula <a href="mailto:pvirkkul#iki,fi">pvirkkul#iki,fi</a>, Thu 18 Nov 1999, 07:34 GMT </LI> <LI><strong><A NAME="00265" HREF="msg00265.html">Re: [MUD-Dev] Languages for MUD drivers</A></strong>, Cynbe ru Taren <a href="mailto:cynbe#muq,org">cynbe#muq,org</a>, Tue 16 Nov 1999, 05:12 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>