[MUD-Dev] Collecting ideas for a MUD server... (fwd)

[Jon A. Lambert]

J C Lawrence wrote:
>On Tue, 21 Dec 1999 17:30:30 -0800 
>Justin Rogers <justin at mlstoday.com> wrote:
>
>>> From: "Wesley W. Terpstra" <terpstra at iota.dhs.org> 
>
>>> I also wanted to know of what MUDs currently implement any of the
>>> following: multithreading, guis, exploiting client processors,
>>> pgp certificates about players so their characters can move from
>>> one server to another w/o the two servers ever talking directly.
>
>> I don't know about existing muds that support too many of those
>> things.  
>
>As mentioned previously, there are several other than myself here in
>MUD-Dev working on multi-threaded, GUI-interfaced, client-server,
>etc etc etc systems.  There's a wealth of knowledge in the archives
>there.  The systems and assumtptions I'm using for Murkle are but
>one set of design decisions and assumptions.  Lambert has a
>different set, as does Wiggins, as does Dr Cat, as does ...etc.


Ok, time to rumble (ramble). ;-)

TychoMud's network and database sub-systems are multi-threaded 
and safe.  The network sub-system was easy since that's the way
servers are commonly handled on my platform anyway and there
is no shortage of experience and solid design information out there. 

The database sub-system was a bit more difficult because most
of the successful proprietary systems run as IPC processes with
their locking mechanisms residing in the database process space.
Obviously this is both a solution and bottleneck to the multi-user
locking problem.  The locking strategies commonly used in rdbms/odbms 
are generalized and so are the cacheing strategies.  Generalized dbms 
cacheing strategies are an anethma to mud servers.  I'm sure the MOO 
or Cold people can attest to this.  Using a proprietary dbms locks one into 
following the object-model (or lack of object-model) used by the dbms 
which may directly contradict the object model followed internally by the 
mud server's programming language.  This is most pronounced in the 
performance of relational databases linked to an object-oriented mud 
server.  Most rdbms that I've seen are not run dynamic although many 
implement DDL which can handle it though it is a very expensive operation.  
I have at various times used Access, DB2, BDE and Interbase.  Actually 
I could use any ODBC compliant system.  Ideally the database system 
should model the object-model used by the mud server _exactly_.   
In any event, I've designed my own object database sub-system which runs
in the same process space as the server and implements Aphrodite's
(the MPL) unique object-model, and all the cacheing and locking quirks
which benefit such a model.  The benefits of mutli-threading here are 
good.  Anytime disk I/O can be made asynchronous, that is a good thing.
 
That said I'm having no end of DIFFICULTY in threading the execution of 
VMs that do the actual work on the server.  A context switch during the
execution of a VM is quite application-centric.  Unexpected or preemptive
context switching is a real pain in the ass here.   Why?  Because the number
of states involved in the execution of a VM are an order of magnitude higher 
than the states present in the network and database sub-systems.  There
is probably a rule of thumb in the last statement regarding the ease of 
implementing muti-threading.  The ease is inversely proportion to the 
number of states present in a system.
Currently I do software multi-tasking through a tick system, not unlike 
Cold, LP, or perhaps Muq I presume.   I hope to get it to work one day since
the problem is not intractable.  BTW, NT fibers may well be a better 
solution to this problem since the context switch is defined and implemented
by the application and not the operating system.  For Linux users, I would
venture that rewriting the context switch code in the PThreads libraries 
to be under application control might give one Linux fibers.  :-)   

Now as for GUI clients, I will only be supporting a specific client written by 
myself.  Currently it runs only on Windows plaforms.  It's written in C++ but 
I make use of only VCL components.  Interestingly enough, Borland is porting 
VCL and Delphi to run on Linux, however I think they will only be supporting 
Dephi bindings and not Builder bindings. I suppose I could rewrite the client 
in Object Pascal, but I'm not looking forward to it.  

>> However, using my WORMHOLE plugin you can easily connect multiple
>> servers that are all running a WORMHOLE program.  I've used this
>> for several space type games I've created with my plugins.
>
>There's also a fair bit of prior art here, from the current
>reasonably well documented InterMUD protocol to the original
>inter-MUD portals Marcus Ranum put in UnterMUD back in the 1980's.
>Stephen White's "YO" object RPC protocol for COOLMUD could also be
>extended to be considered a server interconnect protocol (tho its
>really not on any arbitrary basis).


I've been playing around with YO.  It is a simple peer to peer UDP 
connection and as such is quite easily spoofed.  Ideally such a distributed
server system works best behind a firewall unless some sort of secure
validation process is added.  Because of the object model, _all_ 
interactions between objects take the form of messages or events.
In theory all interaction could be distributed.  However in practice
it must be coded explicitly.  For example, #0 is the system object
for the local server, while #0 at server2 is the the system object
on another server.   So it is indeed possible to construct objects 
remotely on other servers and write code that affects multiple servers' 
objects, however doing so obviously introduces dependencies and 
message traffic between the servers.   What is missing is a mechanism
to register and deregister object catalogs or repository information 
automatically as new servers are brought into the loop or taken out
of the loop.  Without such a mechanism, any code that is written
is explicitly dependent and must be rewritten every time servers are
reconfigured. 

Now the reason I've been playing with YO is not that I'm terribly
interested in distributed systems, though by proxy I probable am.  
Since I'm binding my database system into the same process space 
as the server, I have lost the utility of using external tools to manage 
and query the database.   By implementing YO (or something like it) 
I can implement any of the tools I need as peer server processes.
          
--
--*     Jon A. Lambert - TychoMUD Email: jlsysinc at nospam.ix.netcom.com     *--
--*     Mud Server Developer's Page <http://jlsysinc.home.netcom.com>      *--
--* "No Free man shall ever be debarred the use of arms." Thomas Jefferson *--






_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev