[DGD] Belated return

Wed Feb 11 23:39:42 CET 2015

Ahh, the wonders of topic drift.

As for blain's original question, I have no direct experience but my theory
is one of two things:

1.  You/your client connects to a connection server which itself is
responsible for communication with the servers.  Kinda like how a spirit
representing the user object might jump from body to body, but the spirit
object itself always receives I/O from the user.

2.  The client leapfrogs from server to server transparently behind the
scenes.

As for mud clients, telnet just happens to be a de-facto standard from
being used so much.  If you start from scratch, the sky's the limit.

Heck, I even got my own mud to do animations using nothing but ANSI.

Also, a cautionary tale for dealing with connection overload:

I found out the hard way, but quite early, that once DGD has all slots in
the user table filled, it simply stops accepting new connections, which
without action by DGD tend to pile up in the kernel's accept() queue,
instead of simply being rejected outright as I first thought.

This is fine for quickly processed connections such as HTTP, but for
interactive users, waiting in a dead silent accept queue isn't very fun and
you'll probably want to send them away with an error message.

How I handled this in kotaka was to:
1) Have System::userd handle all incoming connections
2) Keep non-klib connections at least one slot below the config file maximum
3) Promptly close any connections trying to occupy the last slot with a
subsystem configurable error message.

This way, any connections the mud can't handle are cleanly dumped back to
the user with an error message, instead of getting stuck in limbo while
DGD's first in first out structure forces extended queuing, and the
subsystem normally responsible for the connection isn't bothered about, or
given a chance to be, taking a connection that fills the last spot in the
user table (and thus triggers a DGD level fifo response).

As an added benefit, by having System handle all incoming connections
directly and delegating ports to subsystems on request, System is also able
to enforce IP bans

On Tue, Feb 10, 2015 at 7:18 AM, <bart at wotf.org> wrote:

> All good points, but you can have pretty much the best of both (or the
> worst
> of both, depending on your POV) by using a web based client, no additional
> software to install for the user, yet enough client-side intelligence for
> redirection and what not.
>
> A significant hurdle for having a dedicated client for what are essentially
> games built by hobbyists in their spare time is it being yet another piece
> of
> software to maintain, introduces some nice versioning and cross-platform
> headaches. This can be addressed partially by creating a client that can be
> used for many muds, but seeing how the 'mud world' can't even seem to
> agree on
> something as simple as intermud chat protocols or a protocol to query the
> status of a mud, I am not going to bet on such a solution.
>
> Bart.
>
> On Tue, 10 Feb 2015 08:04:42 -0500, Dread Quixadhal wrote
> > And there you have your answer.
> >
> > EVERY MMO out there (to my knowledge) uses a client that was built
> > specifically for that game.  Only the MUD community somehow has a problem
> > with this, probably because the old timers among us cling to the raw
> > TCP sockets which happen to work with most TELNET clients.
> >
> > MUD's did not choose to use TELNET because it was the best choice.  They
> > used it because, at that time, it was the simplest and most readily
> > available client, and didn't require the majority of players to install
> > their own software.  Remember, back in those days you couldn't just
> > set up your own machine on the internet.  Most players were students
> > and had limited disk quotas and might not have been allowed to
> > install custom software, even if they had access to it.
> >
> > On Mon, Feb 9, 2015 at 8:16 PM, Blain <blain20 at gmail.com> wrote:
> >
> > > I was just pondering one day how to deal with a connection limit and it
> > > spiraled out of control to wondering how MMO's handle it with their
> > > proprietary client.  I noticed WoW has multiple world servers and the
> > > client handles the disconnecting and reconnecting on its own.  So to
> > > simulate this in a MUD, one would need to tell the MUD client to do it,
> > > thus limiting one to only doing this for players who are using clients
> that
> > > can handle it or creating ones own proprietary client to distribute and
> > > force all users to use.
> > >
> > > On Mon, Feb 9, 2015 at 7:24 AM, <bart at wotf.org> wrote:
> > >
> > > > On Sat, 7 Feb 2015 16:32:46 -0600, Blain
> > > > wrote
> > > > > Geez.  I'd send them an itemized bill and
> > > > demand for just
> > > > > compensation. ;)
> > > > >
> > > > > I was working on my lib again for a bit,
> > > > but got sucked back into finishing
> > > > > up some project reviewing on AA.  I'm
> > > > really enjoying DGD, though I
> > > > > wish I had more time to devote to my
> > > > project.
> > > > >
> > > > > While I've got your attention, I was
> > > > curious if you (or anyone else that
> > > > > might be listening) would know how MMOs
> > > > seem to hand the client's
> > > > > connection off from server to server, or
> > > > do they just tell the
> > > > > client where next to connect, perhaps?  I
> > > > know that some MUD clients
> > > > > can be told to change connection, but I
> > > > was looking for a way to
> > > > > have two or more servers, one for login
> > > > and one or more for game
> > > > > playing, but yet only give out the login
> > > > server for initial
> > > > > connecting.  It seems to me that basic
> > > > telnet cannot handle such
> > > > > redirection without tunneling and thus
> > > > tying up that port on the
> > > > > login server.  I was just pondering this
> > > > one day.
> > > >
> > > > What is it you want to achieve with this?
> > > > Is the main worry the port being
> > > > tied up or would it be load on that
> > > > specific server.
> > > >
> > > > So far, my experience is that server load
> > > > is a much bigger issue, and is
> > > > easily solved by having a dedicated server
> > > > for session handling, and
> > > > 'background' servers for handling the (cpu
> > > > and memory heavy) game logic.
> > > >
> > > > So users always use the 'login server' and
> > > > are 'tunnelled' to the actual game
> > > > server where they belong.
> > > >
> > > > Bart.
> > > > --
> > > > http://www.flickr.com/photos/mrobjective/
> > > > http://www.om-d.org/
> > > >
> > > > ____________________________________________
> > > > https://mail.dworkin.nl/mailman/listinfo/dgd
> > > >
> > > ____________________________________________
> > > https://mail.dworkin.nl/mailman/listinfo/dgd
> > >
> > ____________________________________________
> > https://mail.dworkin.nl/mailman/listinfo/dgd
>
>
> --
> http://www.flickr.com/photos/mrobjective/
> http://www.om-d.org/
>
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd
>