[DGD] Fatal error when no user object returned

[Raymond Jennings]

Oh yeah, if you're doing a multi-callout upgrade or the like, just
block all the active connections, and insta-reject the new ones.  if
you're using the kernel library you can even suspend callouts.

On Tue, Jun 5, 2018 at 7:42 PM, Raymond Jennings <shentino at gmail.com> wrote:
> Which is why you
>
> a) block connections that are active during the upgrade
> b) reject new connections (with an immediate disconnect)
> c) use atomic functions to catch errors
> d) keep snapshot backups handy if something crashes.
> e) if d and e aren't enough, you do your updates on a test server
> before putting them live
>
> But seriously, I still maintain what I said before.
>
> It's about API consistency.
>
> The driver object is expected to conform to its api as presented by dgd.
>
> If you want to instantly close a connection, just return a daemon that
> immediately disconnects the connection in its open() call
>
> You can have that daemon compiled from driver->initialize if you want
> it available immediately.  From the POV of LPC, only one task at a
> time happens, so the driver->initialize call would return before any
> user connections came in.  They come in serially, one at a time from
> LPC's point of view, and the "connection eating" daemon can dispose of
> them immediately as fast as they come in if desired.
>
> Anyway, as I said, if the driver object is noncompliant with dgd's api
> and gets caught in the act, it's a crash.  Why?  As felix once said
> before, it could be due to a dgd bug that trashed the driver object's
> information.  If that noncompliance is caused by the driver object
> being improperly coded, well...it's the programmer's fault.
>
> Making sure that telnet_connect and family return a persistent object
> isn't that difficult to ensure.
>
> Sorry if I seem pointed, but I feel strongly about this.
> :P
>
> On Tue, Jun 5, 2018 at 4:39 PM, Blain <blain20 at gmail.com> 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