Subject: YO!

From: [email-masked] (H. Peter Anvin N9ITP)
Date: Thu, 6 Aug 1992 11:31:57 -0700

You write:
> 
> 	There is another solution, but it is beyond my capabilities, and
> that is to implement the CoolMUD YO protocol on MOO.
> 
> 	YO is CoolMUD's method of distributing objects.  It sends
> packets which execute verb code on the other side.  CoolMUD is close
> enough to MOO that it should not be such a huge deal to port this
> protocol to MOO.  All that would be needed would be a simple addition to
> handle the #@server notation in the moo code parser and command parser
> and modify YO to handle (ugh) properties.
> 

I don't know if it is just me, but it seems like any such solution would be
ridiculously expensive in terms of network bandwidth, especially if an
object is inherited across a network link.

Also, if I move across a network boundary, all information about me and my
surroundings will have to flow back and forth across the net.

A binary protocol would maybe help somewhat; if systems are ID'd by a
quantity of 5-10 bits a 32-bit representation of object numbers would still
be feasible.  (10 bits would hold 2 monocase letters, allowing for a
#XX99999 notation).  As I see it, the protocol must be able to handle all
of the fundamental MOO operations; most of it can be done by MOO code
evaluation with the extended syntax; some of it (moving, inheritance across
gateways) may be trickier.  Also, there is a permissions question; is Zytor
(#DA2) a player, programmer or wizard when on LambdaMOO (LA)?  When on
ChaosMOO (CH) where all players are wizards by default?  When on Floodplain
(FP) with an all-programmers default, assuming it was still there?

	/Zytor

-- 
INTERNET:  [email-masked]   TALK:      [email-masked]
BITNET:    HPA@NUACC     IBMNET:    16334 at IBMX400
HAM RADIO: N9ITP         NeXTMAIL:  [email-masked]
Have you kissed your Swede today?

---

From: [email-masked] (Glen Daniels)
Date: Thu, 6 Aug 1992 12:16:53 -0700

You write:  (talking about YO)
>object is inherited across a network link.

	Why does everyone seem to think this?  I don't see any reason
why this has to be true.  I would think the main way to avoid the
bandwidth crunch is simply to implement a good caching system!  You
grab the information you need, and store it locally.  The server where
the object "really" lives keeps pointers to all remote copies, so it
can update them if anything important changes.

	Also, compression technology is pretty durned impressive
nowadays (of which I am continually aware as I use my 38.4Kbaud
connection over a normal phone line).  For large data transfers, this
could be utilized to cut the bandwidth again.

>surroundings will have to flow back and forth across the net.

	It's probably not a good idea for you to simply maintain a
single connection to a server, and have all data pumped at you through
there.  If you move, the server should tell your client how to make
another connection to the new server, and perhaps pass both you and it
a unique tag for validation purposes.  Then you maintain the new
connection.  Granted, information needs to pass back and forth between
the servers, but again, it gets cached to minimize the bandwidth.

	As for the permissions question, that's a very interesting can
of worms, and one I'd like to delve into at a later date.  You need a
verifyable identification system, and probably the ability to keep
templates which determine any special features objects get (or lose)
while in particular server-domains.

	** DISCLAIMER : I haven't been MUD/MOO hacking for very long, **
	**		please forgive any obvious brain-damage       **

		--Gub (Glen Daniels, [email-masked])
	"The future exists first in Will, then in Imagination, then Reality."

---

From: [email-masked]
Date: Thu, 6 Aug 1992 14:08:21 -0700

> Why does everyone seem to think this?  I don't see any reason why this has
> to be true.  I would think the main way to avoid the bandwidth crunch is
> simply to implement a good caching system!  You grab the information you
> need, and store it locally.  The server where the object "really" lives
> keeps pointers to all remote copies, so it can update them if anything
> important changes.

All too true.  Distributed database solutions certainly exist.  YO doesn't
cache, and that's a big problem.  Nobody has had the gumption or spare time to
address this yet since current MUD server technology needs to be expanded in
othter directions first.  MOO, COOL, et. al. are still in their adolescence. 
Last I heard, Haakon was going to address some of these other problems this
summer, but I can't speak for him.

One problem that caching brings up is concurrent access -- yucko ptewy.  The
way in which MOO schedules threads sort of sweeps this problem under the rug,
since 'critical sections' are implicit, but in a distributed environment there
is no similar easy way (unless only one server evaled and the rest were mere
database servers ... hmm).  I'm not too sure about this, but COOL seems to
have some sort of locking mechansim to handle this (it has a lock() primitive).

> It's probably not a good idea for you to simply maintain a single connection
> to a server, and have all data pumped at you through there.  If you move,
> the server should tell your client how to make another connection to the new
> server, and perhaps pass both you and it a unique tag for validation
> purposes.  Then you maintain the new connection.  Granted, information needs
> to pass back and forth between the servers, but again, it gets cached to
> minimize the bandwidth.

The most primitive attempt at this was the TinyTalk client which responded to
messages like '#### please reconnect to NUKEMUD ####'.  Nefarious players
included messages like these in their descriptions ...  TinyTalk let you
maintain a list of MUDs with your names and passwords on each, so you would
automagically login to the new mud.  Some versions of the GNU Emacs MUD client
might be able to do this too.

I don't think this is the right approach.  I mean, if you're going to cache db
objects in the first place, than the stuff surrounding the player will get
cached too.  So what if the room you and I are in was created on a different
(non-local) MUD?  All of the processing for our communication would be
accomplished by the local server anyway, so there would be no reason for our
clients to go reconnecting.  If we modify the room, then some inter-server
communication would have to take place, but that's unavoidable even if clients
are forced to reconnect.  The responsibility of the client should be minimized
to the jobs of presentation and fancy input, IMHO.

> As for the permissions question, that's a very interesting can of worms, and
> one I'd like to delve into at a later date.  You need a verifyable
> identification system, and probably the ability to keep templates which
> determine any special features objects get (or lose) while in particular
> server-domains.

I won't pretend to understand this, but I agree that permissions in a
distributed MUD environment is quite the worm can.  I think it can be boiled
down to a system of trusted servers.

SRI SYADASTI SYADAVAKTAVYA SYADASTI SYANNASTI SYADASTI CAVAKTAVYASCA
SYADASTI SYANNASTI SYADAVATAVYASCA SYADASTI SYANNASTI SYADAVAKTAVYASCA

-K*