[DGD] Belated return

Fri Feb 13 10:29:35 CET 2015

Interesting responses.  I came to pretty much the same conclusions.   I
think I'd go with a browser client just for the added benefit of getting
players who aren't telnet-savvy.  With AJAX allowing the page itself to
mutate without relocating or refreshing. the browser seems to have become a
fairly stable environment these days.
On Feb 11, 2015 4:41 PM, "Raymond Jennings" <shentino at gmail.com> wrote:

> 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
> >
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd
>