[DGD] Fatal error when no user object returned

[Dread Quixadhal]

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