Subject: MOO communication

From: Ryan Daum <[email-masked]>
Date: Wed, 5 Aug 1992 11:07:39 -0700

MOO Distribution

	Experiences and ideas for effective MOO database distribution.

	JoeFeedback and a few others have seen the results of my
experiments with MOO distribution, but most seem to be unfamiliar with
them so I will describe what I did and perhaps release the objects in
question to beta.xerox.com in the contrib/moocode directory in a few
weeks in some better form.

	What I have here is remote MOO evaluation of code.  All these
VROOM proposals I've seen disgust me because they are limiting the types
of objects and the nature of the objects that can pass through the
virtual room.  That is, they do not sit at a low enough level and cannot
handle the interesting elements which MOO is useful for: database
changes, new types of rooms, new types of player classes, etc. which may
break the VROOM idea.

	What I had in mind was something that sat at a much lower level,
and that was remote MOO evaluation of code.

	What I implemented, ran, and used, for a week or so, was this:
	
	On my local MOO:
	
		Network Room:	A room which contains a variety of relaying
				devices.
				
			Contents:
				LambdaMOO Relay Device (#85)
				
	On LambdaMOO
	
		Player Entarte_Welt:	A player who's sole purpose is to
					retrieve evaluations from LambdaMOO
					via Everyman:eval.
					
	A session would start like this:
	
		@start #85
		LambdaMOO Relay Device connected to lambda.parc.xerox.com 8888
		Player logged in.
	
	From that moment on typing:
	
		;#85:eval("4+4")
		
	Would send ;4+4 to LambdaMOO.
	
	The advantage is that because we are able to execute and
evaluate code on a remote MOO, we can actually attempt to distribute
objects by playing nice tricks with :* verbs and such.  Of course, this
approach has huge problems, and I never sorted out how I would do the
actual distribution, but it certainly aids and adds to the usefullness
of any sort of distribution.

	Now comes the ugly part.
	
	My first problem lay in the way open_network_connection works. 
Instead of just opening the connection and reading the lines one by one
as they come, one has to set up a seperate task which filters (weeds)
its way through the text and does stuff with it, and another seperate
task to send.  By seperating the two, one has the problem of not knowing
which returned values represent which eval statement.  The read and
write processes are out of sync, and there is no real solution for this
other than marking every returned value with a unique identification
stamp -- which is what I am now attempting to do.

	The second problem is lag.  Not only have I no idea which
returned values represent which eval statement, but lag utterly screws
up any timing.  If I send eval("4+4") I have no way of knowing when the
result is going to come, so the best I can do is guess and put a suspend
for a huge amount of time in my get_returned_value loop.  This, of
course, reduces speed by a huge margin, and is often innacurate.  What
would end up happening with me is things like this:

	player:tell(#85:eval("4+4"));
	8
	playeR:tell(#85:eval("#18502:tell(\"hi, Comrade, this is you
speaking from the OTHER SIDE\"));
	8
	player:tell(#85:eval("4+4"));
	0
	
	You get the idea.
	
	Solutions?
	
	My first idea is to hack this system by
	
	a) adding unique ID "stamps" to every item sent to the other MOO.
This would allow some resemblance of sync between read and write.

	b) creating some sort of loop which waits until it knows for
sure that the returned value belongs to it.

	The downside of both of these solutions is that they slow down
the system further, and make it even *more* of a hack.

	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.

	Instead of just executing code on the other side, YO actually
accomplishes a actual distribution by making the objects available for
use in a traditional manner on both sides of the MOO.  One refers to an
object YO also has its problems.  It is not very efficient
or useful for wide area networks.  Its only real usefullness is in a
small local area network.

	The third solution, as far as I can see, is to implement what I
described above (the remote evaluation via open_network_connection) as
an actual protocol.  The advantage over YO is that it would not use up
so much bandwidth, and would perhaps allow for more creativity.  On the
downside, YO actually does a distribution of objects, whereas my
solution requires extra MOO code to pretend the objects are distributed.

	Big enough message? :-)
	
	Ryan Daum	[email-masked]	Comrade@LambdaMOO
						Former Archwizard of
							Floodplain and
							a guy with too
							much freedom
							to put MOO
							servers up :-)