[MUD-Dev] mud client development systems

[Jay Carlson]

Sunny Gulati wrote:

> Wow.  You folks are all amazing.   I'm getting more feedback than I have
> bandwidth to investigate thoroughly :)
>
> Many thanks to Scatter for his/her pointer towards MudOS's ability to do
> a secondary raw binary port built in to the mudlib.  That's #1 on my
> list to check out.  And I'm going to take a peek at Chris Gray's socket
> code.. that's #2.

If you have multiple TCP connections per logical connection to the mud, you
run into:

  o  Security problems.  You may end up fighting with firewalls and proxies;
you may end up with a pain in the rear trying to get the second connection
open without races.
  o  Loss of synchronization.  There's no ordering of events received
between the connections.  This may or may not be a problem for you, but I
would think it very disconcerting to have my text window get 30 seconds
ahead of the rest of the UI of the client.

Conventional wisdom in my circle is that Chris's solution of having a port
per type of protocol spoken (line-of-text, telnet, binary) is the way to go.

> Going to let my mind wander some more...
>
> I was talking to a friend (I don't remember who) (in real life) (I think
> it was my boss, AlanS at E-Markets.com), and he said:
>
>   "Sounds like you're trying to implement CORBA on a mud".

MCP is sorta like that---it's a metaprotocol, with no particular semantics.
Packages like simpleedit are like CORBA facilities.

But CORBA (as widely implemented) doesn't seem appropriate for a naive
implementation  of a mud client/server interface.  If you implement the bulk
of your protocol as conventional method calls, you'll be eaten alive by
round trip times on the method returns.  If you then use oneway methods, you
give up synchronization and end up building a higher level protocol to get
that and reliability back.

What you really want is something more like an event service, but the CORBA
event service doesn't fit very well; for instance you frequently need to
subset the groups to handle events only visible to some.  (Whisper is a
simple example.)  Oh yeah, most of the good event service implementations
cost Real Money.

MCP does some very smart things for typical mud applications, or rather,
allows protocol designers to do very smart things.  No question that writing
a bog-simple CORBA interface will take less time. I haven't decided yet what
the relative costs are to design efficient and correct MCP vs CORBA
interfaces.

Probably the canonical public example of a smart protocol is protocol
negotiation. http://www.moo.mud.org/mcp/mcp2.html#startup is like telnet
option negotiations on steroids.  Neither side has to wait for the other and
both can pretty much start streaming data at each other before the entire
negotiation is complete.  Other examples I know of involve pushing object
information at clients before they know they need it, and a system for doing
the Right Thing with multiple users editing forms at the same time.

> More dreamy stuff:
>
> Talking to another friend Steve (wells at cedarnet.org), and he was
> interested in doing some Perl/GTK or Java client-side coding if I got my
> ideas along far enough.  This got me thinking, on the 2 hour drive back
> from his place.. he wants to play, but its not the same place that I am
> looking at playing... I want to do Perl/Tk (just because)... and Matt
> Messier, another friend, would want to work in C++..
>
> -> i wonder if I can make my client side objects language independent?
> I mean, if Steve likes Perl, he can write a client in perl, and the
> mudclient in question can still use it, even if its written in... uhhh..
> picking shocking language.. uh..  COBOL!   :)
>
> -> Obviously, it would have to run in a seperate process.  Need to
> communicate back to the master client program (which has the connection
> back to the mud).  How should I do this?

I've heard the idea of "mcpswitch" tossed around a fair amount.  It's the
same idea as your master client.  There'd be some configuration that told
the switch what processes to launch when particular request types came in,
or perhaps you'd start up the MCP-speaking subclients at mcpswitch startup
time, and they'd just do their own private mcp-negotiate session with the
switch to set up what things they wanted to deal with.  Cords are the
obvious way to handle instantiable objects to be communicated with (as
opposed to static methods).

This starts to look *just like* the various activation policies in CORBA,
especially the IR.

>       .link.   could be the telnet link (okay okay socket connection
> between client and mud)
>                left side is client, right side is server
>       switcher.link  is the main switcher object.  Its written in perl,
> for example
>       chat.switcher.link  is the chat thingy written in perl (lives
> directly off the switcher)
>       5.chat.switcher.link  is the particular instance that we're
> talking to.
>       java.switcher.link is the java handler
>       198.java.chat.switcher.link is the java instance of a chat
> handler.

Cords were designed with this kind of addressing as opaque, mostly because
we weren't intending to do any kind of routing based on them.  This means
that the hypothetical mcpswitch would have to do the moral equivalent of
network address translation to make sure that cord ids didn't conflict.

>
> Wow, that's way too long to be useful.  Maybe some sort of unique number
> could be arbitrated? (ugh).  Then again, it doesn't need to be human
> readable - could just have:
>
>        198.3.45.1.0

The analogous service is the CORBA Naming Service, which maps human-readable
names into object references.

Jay