From: Andrew.Wilson@cm.cf.ac.uk (Andrew Wilson)
Newsgroups: rec.games.mud
Subject: Re: Inter-MUD communication.
Date: 30 Aug 92 19:20:23 GMT
Organization: University of Wales College of Cardiff, Cardiff, WALES, UK.



Hi,

	Stephen White (ghond@sloth.nmsu.edu) says:

>COOLMUD goes further than MOO-net, in the sense that *every* operation
>that you can perform on local objects can be performed on remote objects.
>In fact, if an object works *at all* on the local machine it will
>work over a remote link.  There is no way to code a non-transportable
>object or operation.

>Originally, I used dedicated TCP connects between all connected mud's.
>This turned out to be too slow, so I switched to UDP, since I was
>already doing my own timeouts and sequencing, and the packets are 
>small.

I've heard quite a lot about COOLMUD, most of it's good and some of it is quite amazing!
CM's just about THE most advanced design of text OOVR system available atm, and the idea of
having a 'remote' capability as a pre-requisit to a server's design is unique I think.

I should point out however that one deliberate feature of MOO-net's design is the ability
of sites to relay information sent by others to their ultimate destination.  This enables
MOO-net to have any topology and is instrumental in overcoming several polotical problems
which occur when you try to connect other people's sites to your network.  Not every
site in the network will have the same capabilities.  LambdaMOO for instance, the biggest
and most advanced MOO there is unable to make outgoing connections to internet.  It's
essentially blind and relies on other sites to relay information from it to the rest of
the MOO-net.  It's also useful for security reasons to allow other sites to have access
to your MOO without publishing the ADDRESS/PORT details for general consumption.  Basically,
a single site may not want or need to know the details of every other site in the net.  I
don't think it's a good idea to assume, for the long term, that EVERY site will know where
every other site is.  But anyway, this is all presuming a lot about COOLMUD's design.  Does
a COOLMUD network have all it's sites interconnected or can you, for instance, connect all
the sites together in a ring, or any other topology?

>All the message handling code is in C, but interpreting the messages
>is up to the objects in question (messages are passed object-to-object,
>not server-to-server).

I'm interested to know your thoughts about sending object identifiers across a net.
I've experimented with ids like '#1234@LambdaMOO' which would go some way to uniquely
identifying an object amongst all the objects on all the servers in the network.
There are more fundamental considerations however, specifically should an objects physical
location in the network be a concern of the users of that object. Suppose you wanted to
get a list of all the objects 'contained' within another object.  Would you code it like
this:

(1)	Contents = MyObject:contents();

meaning that the server itself decided whether the object identifier held in 'MyObject'
referred to an object on the host server or on another server in the network.

Alternatively, would you code it like this:

(2)	if (IsNetworkObject(MyObject))
		Contents = TheNetwork():request("GET_CONTENTS", MyObject);
	else
		Contents = MyObject():contents();
	endif;

by which I mean that the programmer has to be able to predict what sort of object
he's dealing with, be it a foreign object or a local one. The code fragment in (2)
is the way I've been doing it in MOOnet.  If the object is of the form '#1234@LambdaMOO'
then I ask my network object to retrieve the desired results from that object's host
site, where ever it may be in the MOO-net topology.
	Note that in (2) the programmer still doesn't know WHERE the object really is,
but he does know that the object isn't on the host server.  This happens as a result
of the nature of the current MOOnet implementation which, as a pre-requisit of the project,
does not seek to redesign the server and uses only the facilities that the Core database
package provides.  In (1) things are MUCH cleaner and more simple.  (1)'s programmer
doesn't know the nature of the object nor its location.  Simply put, I think that (1)
is the better way to do this, which implies that existing servers SHOULD have a much greater
networking potential than they have at present.

It's probably too early to say whether or not a networked family of OOVR systems would
be successful, either in terms of being used by lots of people or even being fast enough,
in spite of their additional work load, to be managable.  I think that there ARE genuine
reasons now for designing systems with a networking capability.  I consider that the
VROOM experiment, which was the principal reason that MOO-net came about, has been a success.
VROOMs have shown (shown me and a few others at least), that a networking capability can
bring a new and useful dimension to the usage and evolution of our type of VR system.
In the design of MOOs, LPs and all the other M**s there is still room a need for much further
innovation.


It never ceases to amaze me that M**s, so much creatures of the internet, have no way
to see and exploit the environment in which they find themselves.  If you are about to
embark upon the design and implementation of the next generation of VR systems then please
give them the features they deserve to make this possible.


Andrew Wilson - Networker @ Internet
Newsgroups: rec.games.mud