Subject: A peer-to-peer idea

From: Lincoln Myers <[email-masked]>
Date: Tue, 24 Aug 1993 23:13:05 -0700

My recommendation for how to best implement another generation of mud that's
beyond telnet (text or graphics or 3d or whatever tinkles your bell) would
be to have the client and server combined into one.

Essentially, instead of running TinyFugue or Telnet or TinyTalk, you run
LambdaMOO.  Your MOO and the server MOO then send messages to each other,
allowing the sorts of things you'd expect from a smart client, and then some.

Here are the advantages that I see of this approach over making a very
specific protocol and a number of special clients.

	- The client is programmed using MOO, not C, so it carries the same
	  advantages: easy to program, and much more portable.

	- Most importantly, entirely different protocols can be added on
	  after the fact.  The system would be set up such that
	  communications are established between related objects, allowing
	  unrelated objects and therefore protocols to be out of each
	  other's way.  Here's an example:

		Carrot's scrabble server object would talk to Carrot's
		scrabble client object in whatever protocol he felt was best
		for scrabble.  Brand's Distributed Peer-to-Peer Markov
		Chainer objects could communicate in whatever way he felt
		was best for Markov chainers.  Carrot and Brand never needed
		to agree to any sort of convention, yet the MOOs communicate
		in a way which is appropriate for both playing scrabble and
		chaining Markovs. :)

	- The client can share some of server's computational work, allowing
	  faster response from the server.  (and faster response overall if
	  it's something the client can mostly handle alone, e.g. a message
	  could be edited on the client with faster response and sent to the
	  server only when finished)

Here are my thoughts as to how to implement this:

	- Give the MOO itself better screen control (over the console and/or
	  logins on the same machine) through curses, tcl/tk, or tek4014
	  sequences.

	- Enhance the ability of the MOO to send data over the net,
	  specifically by setting up a protocol to allow sending of lists,
	  strings, integers, etc. as descrete units, rather than converting
	  to/from text.  Reorganize net connections to more easily allow and
	  regulate sending messages between objects on different servers.

Of course, there are also disadvantages:

	- Security is now an issue, since the client MOO is much more
	  responsive to the outside world.

	- Even though the server MOO will be likely to be more responsive
	  than a server under a more traditional approach, the client is
	  likely to be slower since it is now interpreting code.  For text
	  based stuff this shouldn't be a problem, but for 3d...

I think this is a good idea, even if one were to still use top-down scrolling
text, but it becomes even more useful as the client needs to become more
intelligent.  I say that if the client and server both need to be featureful
in the interpreting and storing/recalling data departments, you might as
write/modify one program instead of two.

Lincoln (Brand at LambdaMOO)

---

From: Greg Hudson <[email-masked]>
Date: Wed, 25 Aug 1993 05:01:35 -0700

> Essentially, instead of running TinyFugue or Telnet or TinyTalk, you
> run LambdaMOO.

> The client is programmed using MOO, not C, [...]
> Entirely different protocols can be added after the fact.
> The client can share some of server's computational work, [...]

I don't think these goals are well-served by running MOO itself.
LambdaMOO uses a heavyweight object system, and, even with a
stripped-down core, is likely to take up too much space and CPU time
to be useful as a client for most people.  In fact, I would think that
only a few people would be able to run it.

There is already a programmable client, Vaportalk, available from
ferkel.ucsb.edu.  Its language, VTC, is C-like but not terribly
similar to MOO.  Although VT is a "finished" project (I don't plan on
releasing any more updates), it's stable and lightweight enough for
most purposes.

Of course, there is the obvious disadvantage that new players must now
learn *two* languages, MOO and VTC.  I don't think this problem is
solvable until someone comes up with an interpreter that is suitable
as both a server and a client.  I hope that Coldmud will end up this
way, but of course that's vaporware.

> strings, integers, etc. as discrete units,

This should probably be done in-db, perhaps with the assistance of a
toliteral() and parse_literal().

It's worth noting that another server, Coolmud, addresses this problem
in the more general sense: it allows you to send messages to objects
on other servers.  Object IDs are of the form #number@host.  In
theory, any method which works locally should work when acting on a
remote object.  However, Coolmud is network-intensive and not suitable
for a wide-area network.  Moreover, Coolmud imposes the constraint
that parents must be on the same server as children, so you can't have
an inheritance hierarchy spanning two servers.  (By contrast, the
Untermud server imposes a topology on the mud, much as Tinymud does,
and 'caches' remote objects on servers according to which server owns
the room they are in.  Untermud's distributability is not nearly as
seamless as Coolmud's.)

> I say that if the client and server both need to be featureful in
> the interpreting and storing/recalling data departments, you might
> as [well] write/modify one program instead of two.

Only in rare situations can the functionality of a client and a
corresponding server be identical.  This is especially the case when
your model (as presented in your message) is centralized, and not
peer-to-peer.

--GBH