From: ghond@acca.nmsu.edu (ICE-9)
Subject: Re: Inter-MUD communication.
Organization: freakbeatsamplemode
Date: Mon, 31 Aug 1992 06:27:23 GMT

In article <1992Aug30.192024.24663@cm.cf.ac.uk> Andrew.Wilson@cm.cf.ac.uk
(Andrew Wilson) writes:

> 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.

Currently, COOLMUD servers must communicate directly.  There cannot
be any forwarding of messages.

The COOLMUD server's default operating mode is one in which it only
accepts 'connections' (udp packets) from known servers.  However, a
command-line option enables "promiscuous" mode, in which it will
accept connections from any server, and dynamically add them to the
server list.

> 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?

Currently, all servers must be aware of all other servers which it
wishes to communicate with.  These can be added statically, or
dynamically (as above).  Since there must also be (currently) a
single name space for all servers (there can be no two servers
with the same name), I had thought about providing a dynamic
"who's that?" service in promiscous mode.  Eg.,

3 servers, joemud, foomud, and fredmud.
joemud knows about foomud, but not fredmud.
foomud knows about joemud and fredmud.

#22@foomud wants to move into #5@joemud
#5@joemud asks #22@foomud, "who owns you?"
#22@foomud says, "#8@fredmud"
joemud doesn't know what fredmud is, and asks foomud, "who's that?"
foomud tells joemud the address & YO port, and joemud then connects
to fredmud.
... etc.

> 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.

That's exactly how COOLMUD works.  Each server must have a unique name,
and all object references of the form #1234@LambdaMOO are then unique
in the universe.  UnterMUD works much the same way, I believe.

> 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();

In COOL (the temp var is named 'cont' so as not to conflict with current
object's "contents"):

	cont = MyObject.contents();

In fact,

	cont = MyObject.contents;

would do the same thing:  pass the message "contents" to the object
MyObject.  The '.' operator always causes a message to be passed.

> Alternatively, would you code it like this:

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

This isn't necessary, since the COOLMUD server figures out whether
the object is local or remote, and passes the message as appropriate
(passing it directly if local, or sending out onto the net if remote).
Ideally, the COOLMUD programmer should never have to know whether she's
dealing with local or remote objects.

Things aren't quite that simple, however, since remote servers may
be down, networks may fail, etc.  Passing a message to a downed server
causes the exception E_SERVERDN to be raised in the method.  Programmers
must be aware of this, and deal with it appropriately.  How it is
dealt with may vary depending on the task being performed.  For example,
paging a player on a downed server is easy enough; just display an error
message to the user.  Trying to remove an object contained in an object
on a downed server is a little more tricky.  The default COOLMUD boot.cl
(universe rules) deal with this by maintaining a list of remote objects
contained in local objects.  This is all written in COOL; I can explain
further if you like.

(Note that the programmer _can_, if she wishes, determine whether
an object is local or remote using the serverof() and servername()
functions to strip off the server portion of an object ID).

> 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.

True 'nuff.  The thoroughly networked possibilities of COOLMUD (such
as having remote objects sit in local rooms, etc) are probably best
utilized over local Ethernets, currently.  Remote WHO and paging
are trivially implemented in-server, and could probably work fine 
over long-haul nets.

COOLMUD has also been used as a standalone system similar to MOO,
with the advantages of multiple inheritance, a more complete
object-description language, and a better method/verb interface.

> 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.

I did not mean to trivialize the MOO-net project at all; what you've
accomplished is remarkable (and entirely in MOO code!).  I was just
indulging in some shameless self-promotion, for people who may not
have heard of this particular "networked" MUD.

-- Stephen
-- 
stephen white			| the priests and the friars
ghond@sloth.nmsu.edu		| approach me in dread
				| because i still love you,
				| my love, and you're dead - not s. o'connor