[DGD] Fatal error when no user object returned

[bart at wotf.org]

I'm running a persistent live game, and have been for over 15 years now. I
have made changes to networking code, including things like adding a web
server, adding support for intermud 3, recently did some changes to the low
level code handling mudmode and the like.

This all is pretty easy without risk of crashing the mud.

Essential for this is to separate the 'user' and the 'connection'
functionality. A connection object (the one you return on getting a new
connection) should be just that, and administrative object that exists
exclusively for tracking that specific connection, and optionally link it to a
user object. The create function of the connection object is extremely limited
and written such that in case of failure, it will still complete (all errors
are caught and handled later).

Making changes to the code handling http connections, telnet connections,
websocket connections or anything like that does not involve changing that
conenction object, and hence you can easily make such changes without the risk
of the connection object failing its create and crashing the mud.

As a nice bonus, you get a much better opportunity to handle errors during a
connect, and you can keep the 'user state' even when the connection itself is
lost. Useful? Yes absolutely, think about non persistent http connections
which should be tied to the same user object (because of belonging to the same
session) and being able to simulate connections over udp just to name 2 examples.

If your design puts code for handling protocols in the connection object
itself, your design is likely to cause various problems, including the one
that triggered this discussion. It really should be as simple and robust as
technically possible.

To me, networking is primary functionality for dgd, there is preciously little
you can do with dgd when networking fails.

Bart.

On Tue, 5 Jun 2018 18:39:34 -0500, Blain wrote
> The key to a persistent game is being able to do maintenance while 
> live and having years of uptime.  Never ever touching your main 
> ports kinda goes against that.  If a miscalculation occurs during an 
> upgrade, especially an automated one, the whole MUD could go down 
> incestuous when joint is truly broken or irreparable.
> 
> On Tue, Jun 5, 2018, 18:33 Dread Quixadhal <quixadhal at gmail.com> wrote:
> 
> > Good practice says you’ll never work on the live user (or socket) object,
> > but instead setup a secondary port to use for your test connections.  As we
> > all know, programmers seldom follow good practice, and mud
> > admin/programmers very rarely so. 😊
> >
> > That said, it *IS* not entirely obvious that working on the LPC web server
> > might cause your entire game to crash, since part of the allure of an LPMUD
> > is the isolation of systems, so errors in one don’t affect others.
> >
> > Sent from Mail for Windows 10
> >
> > From: Raymond Jennings
> > Sent: Tuesday, June 5, 2018 16:19
> > To: All about DGD and Hydra
> > Subject: Re: [DGD] Fatal error when no user object returned
> >
> > Which is why you need to be careful what user object you return from
> > the driver.
> >
> > You won't even be receiving connections until driver->initialize
> > returns, and you can use that time to set up a dummy user object that
> > can bounce unwanted connections.
> >
> > Dworkin, you want to weigh in here?   My guess is that the driver
> > object is held to high standards with dgd calls.
> >
> > On Tue, Jun 5, 2018 at 4:14 PM, Blain <blain20 at gmail.com> wrote:
> > > I just see network connections as secondary to DGD's purpose.  If someone
> > > is working on a user/socket object and messes it up temporarily, a random
> > > user/metro connection trying to connect will suddenly kill the whole game
> > > for no real outside.  Obviously, a lib can work around this, swapping out
> > > for a dust object, etc.  Be mistakes Sy happen and I think an error for
> > be
> > > generated and connection closed without further effect.
> > >
> > > On Tue, Jun 5, 2018, 18:10 Raymond Jennings <shentino at gmail.com> wrote:
> > >
> > >> This is just my opinion, but if you violate the driver object's API
> > >> you deserve to crash :P
> > >>
> > >> at least one case in the past, regarding missing functions in the
> > >> driver object, receives similiar treatment.
> > >>
> > >> The reason then was that a missing function could have been due to the
> > >> driver object's function table getting trashed.
> > >>
> > >> My guess is that from DGD's point of view, when a fundamental API in a
> > >> core object such as the driver object is violated, it's more likely
> > >> that it's because of a DGD bug.
> > >>
> > >> On Tue, Jun 5, 2018 at 2:26 AM, Blain <blain20 at gmail.com> wrote:
> > >> > I don't see the purpose.  Not every port mentioned in the config file
> > is
> > >> > necessarily critical to MUD operation.  Sure, it's easy to do a
> > >> workaround,
> > >> > but I question the purpose of the explicit fatal shutdown.  A dust
> > object
> > >> > would need to be simple so as not to bug out of an interest or
> > included
> > >> > file happened to be unstable.  The sudden shutdown would lose any data
> > >> > since the last data dump.  Keeping the game up and running and player
> > >> data
> > >> > intact are extremely important on a MUD.  I don't see this as a valid
> > >> > excuse for losing data.
> > >> >
> > >> > On Tue, Jun 5, 2018, 01:34 Raymond Jennings <shentino at gmail.com>
> > wrote:
> > >> >
> > >> >> In My Opinion (tm):
> > >> >>
> > >> >> Failing to return the proper type in a driver hook is a fundamental
> > >> >> API violation.
> > >> >>
> > >> >> However, I think you can still just cause a runtime error and not
> > return
> > >> >> at all.
> > >> >>
> > >> >> Plus you could always have a burner object that just disconnects
> > >> >> immediately when it's assigned a connection.  Not that hard.
> > >> >>
> > >> >> On Mon, Jun 4, 2018 at 11:26 PM, Blain <blain20 at gmail.com> wrote:
> > >> >> > Instead of closing DGD when no user object is returned, would it be
> > >> more
> > >> >> > prudent to just close the incoming connection?
> > >> >> > ____________________________________________
> > >> >> > https://mail.dworkin.nl/mailman/listinfo/dgd
> > >> >> ____________________________________________
> > >> >> https://mail.dworkin.nl/mailman/listinfo/dgd
> > >> > ____________________________________________
> > >> > https://mail.dworkin.nl/mailman/listinfo/dgd
> > >> ____________________________________________
> > >> https://mail.dworkin.nl/mailman/listinfo/dgd
> > > ____________________________________________
> > > https://mail.dworkin.nl/mailman/listinfo/dgd
> > ____________________________________________
> > https://mail.dworkin.nl/mailman/listinfo/dgd
> >
> > ____________________________________________
> > https://mail.dworkin.nl/mailman/listinfo/dgd
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd


--
https://www.bartsplace.net/
https://wotf.org/
https://www.flickr.com/photos/mrobjective/