[DGD] Fatal error when no user object returned

Blain blain20 at gmail.com
Wed Jun 6 01:39:34 CEST 2018


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



More information about the DGD mailing list