[MUD-Dev] Multiple clients (was Re: How to support 1000+ simultaneous connections)

Matthew D. Fuller fullermd at futuresouth.com
Thu Mar 11 20:21:06 CET 1999

On Thu, Mar 11, 1999 at 01:26:04PM -0800, a little birdie told me
that Caliban Tiresias Darklock remarked
> On 08:39 AM 3/11/99 -1000, I personally witnessed Nathan F Yospe jumping up
> to say:
> >On Wed, 10 Mar 1999, Caliban Tiresias Darklock wrote:
> >
> >Of course, I have none of your qualms about a dedicated
> >client...
> The primary reason I don't like dedicated clients is that I want to play
> all my games from the same client. I play too many different kinds of games
> to lock myself into some dedicated thing. I would consider it virtually
> mandatory to release the protocol specs to the community, so a thoughtful
> client author could add support for your server to his own client.
> (Usually, this happens because a half-dozen persistent players bother him
> to add it -- and it helps a lot when they can point him at a detailed
> description of the implementation.)

Interesting datapoint from my present (going absolutely nowhere, but
doing it quickly) project.

One of my design goals is as much flexibility (immediate) and
customizability (simple codewise) as possible.  In the module that
handles the client connections, everything is designed to support some
number of clients ** N; from CLIENT_STREAM, for telnet or your related
client-of-choice, to CLIENT_DATAPACK, for a planned Java client.  And
it's fairly trivial to add more CLIENT_* types (I expect we won't fill up
an unsigned int anytime soon ;) to your heart's content.  All the specs
for additional types will, eventually, be written up in nice little
packages for client designers, and a subgoal is that all SHOULD have the
same basic necessary information.  Obviously, the person using the Java
client will see a bunch of cute little graphics, and the person using
telnet won't, but all the information necessary to PLAYING THE GAME
should be presented universally; thus no client type has a buitlin

We're moving very slowly on this project because we want to avoid
programming in any idiotic ideas and having to work around them later.
Lots of fun though  :)


| Matthew Fuller     http://www.over-yonder.net/~fullermd |
* fullermd at futuresouth.com       fullermd at over-yonder.net *
| UNIX Systems Administrator      Specializing in FreeBSD |
*   FutureSouth Communications   ISPHelp ISP Consulting   *
|  "The only reason I'm burning my candle at both ends,   |
*    is because I haven't figured out how to light the    *
|                     middle yet"                         |

MUD-Dev maillist  -  MUD-Dev at kanga.nu

More information about the mud-dev-archive mailing list