Subject: Inter-MOO communication IV

From: Andrew Wilson <[email-masked]>
Date: Fri, 14 Aug 1992 05:38:11 -0700

Hi,

	for the past two weeks I've been working on the implementation
of a networking system which allows MOOs to communicate with each other.
The networking system is a necessary precursor to the implementation of
VROOMs and to the implementation of a distributed object environment which
would (I hope) eventually allow objects which physically exist on different MOO
sites to interact with each other.

THE DEVELOPEMENT ENVIRONMENT

The networking system has been developed using version 1.5.0 of the MOO server
and the LambdaCore-13Dec91.db database from parc.xerox.com.  I have not yet
looked at version 1.6.0 of the server or the latest LambdaCore.  The hardware
comprises a heard of Sun workstations connected over ethernet.  I've had
six of them interconnected, one MOO per machine with no problems.

ABOUT THE NETWORK

The networking system permits any number of MOO sites to interconnect
in an arbitrary manner.  Connected sites communicate by sending coded
'packets' of data to each other.  A simple command permits any verb to
receive responses to 'requests' it makes to the network.  For example the
code fragment:

	Topology = TheNetwork:request("NETWORK_TOPOLOGY");
	player:tell("Network Topology = ", Topology);

asks the network to return a text string indicating the interconnectedness
(Big word?  Big concept!) of the network.  Put simply (very simply!),
the request is serviced by asking each connected site in turn to
list all the connections it has made to any other site.  A typical response
for my domain would be:

	Network Topology = opal->sapphire sapphire->opal sapphire->ruby ruby->sapphire

Where the '->'s indicate the direction of data flow in the network. This response
is for a network consisting of the three sites, opal, sapphire and ruby.
Opal has a two-way connection with sapphire and sapphire has a two-way
connection with ruby.
	With a network of this form, where opal is not directly connected to
ruby, any requests made at opal are relayed to ruby by firstly passing them
through sapphire and then on to ruby. The ability of a site to relay messages
which are not intended for that site enables complex networks to be designed.
Try drawing this network for the sites a, b, c, d and e, for example:

	a->b
	b->c
	b->d
	c->e
	d->e
	e->a

In this case all the connections are one-way but the networking system can handle
this and all requests made to the network can still be serviced.
	The network has a built in fail-safe to stop 'lost' packets of
information circulating throughout the network for ever. In addition, requests
made to the network will eventually time-out to prevent the calling verb from
hanging indefinately when the request can not be serviced due to extreme
net-lag or because of a crash at one of the MOO sites.

VROOMS (Ring the bells, ring the bells!  Let there be light! etc.)

	They work.  I know I've said as much before but I can prove it
now.

DOES ANYBODY CARE?

	The Inter-MOO network experiment is now in a stable enough state
to involve other sites.  I'd like to hear from responsible people at MOO sites
who would be interested in getting involved with setting up an experimental
long-haul network between my domain at Cardiff University in Wales and their own
site.  Your interest, though much appreciated, would not guarantee that your
site would be involved at an early stage.

WHAT I NEED TO KNOW

	Let me know who you are and what position you hold on your MOO and
give me the MOO's IP address.  If I can't visit you from Cardiff then the
network won't be able to visit you either!

WHAT YOU NEED TO KNOW (For the time being.)

	Your site's server MUST allow the open_network_connection() built-in
to be called. Ideally you should be a wizard because there'll be a LOT to do to
get the system up and running. You'll also need physical access to the machine
your MOO runs on because you'll need to keep an eye on the state of the
(internet) network and things like cpu usage.  If you know about 'netstat' and
'top' in UNIX then you probably know enough.

Please post any questions you may have to [email-masked] so
that we can all join in.

Thanks,
	Andrew "Nope, there's absolutely NO WAY it's going to work!"
	Wilson.

---

From: [email-masked]
Date: Fri, 14 Aug 1992 13:33:10 -0700

I'm thinking of starting a MOO.
Since DEC has kindly agreed to give my lab quite a bit of new 
equipment, I'd like to know what I should ask for.  What is 
the dream machine, and what is the minimum?  How will the
requirements change after MOO goes disk based?

I was thinking of asking for a Decstation 5000 with 128 Mb RAM
and 1 Gb hard drive.  Or should I ask for something more?  :-)
Anything else I need to go with that? 

-- Amy

---

From: Pavel Curtis <[email-masked]>
Date: Mon, 17 Aug 1992 16:33:16 -0700

> Date:	Fri, 14 Aug 1992 13:33:10 -0700
> From:	[email-masked]
> 

Stop now, before it's too late!

Oh, well, since you appear to have your heart set on it...

> requirements change after MOO goes disk based?

The dream machine has infinite CPU speed and infinite disk space.  The minimum
for a moderately-large place with good backups is about 100 megabytes of disk
and about 32 megabytes of physical memory; the CPU speed will likely be fine no
matter what DEC machine you get.

When the DB goes disk-based, the memory requirements will drop to about 5-10
megabytes and the disk requirements will drop by about a factor of two.

> Anything else I need to go with that? 

That'll do you just fine for quite a long time... :-)

	Pavel