[DGD] Fatal error when no user object returned

Wed Jun 6 05:06:22 CEST 2018

On Tue, Jun 5, 2018 at 8:00 PM, Dread Quixadhal <quixadhal at gmail.com> wrote:
> I guess the question is what role DGD is supposed to perform.
>
> Is it a mini-operating system or virtual machine, meant for use by professionals?  Or is it a tool to help people create games and applications where they might lack the experience or discipline to simply code them in their native environment, using their native tools?

In my opinion, both.  However, it's designed as a mini-os vm thing on
top of which you can build a library that youc an then put a mudlib on
top of.  Notice that phantasmal compares to mudos in terms of
complexity for example,a nd yet itself is composed of multiple layers
that go farther and farther away from being game related.  The closer
to DGD a particular layer is, the less you wanna screw with it and the
more careful you want to be.

> If the person running any given server is supposed to be a professional whose skill level is appropriate for running a professional level service, then an unforgiving adherence to the API is exactly the correct approach, since they should know better and shouldn’t touch things the don’t fully understand.

The low level api presented by/to the driver object, yes.  Other APIs
in different parts of the code that deal with players, livings, verbs,
actions, and combat etc, not so much.

The times when dgd fatals on an api clash are rare and when
interfacing with low level objects, like the driver object, and times
where basic consistency is essential for the proper functioning of the
upper layers.  To be quite blunt, those kinds of screwups are very
fundamental, very simple, and quite honestly in my opinion if you
can't get the low level but simple stuff right enough for dgd not to
croak, you probably shouldn't be messing with it.  The kernel library,
for example, was designed to be a low level wrapper around dgd and
keep things simple

> If, on the other hand, you are trying to attract non-programmers to the genre and give them a platform to experiment on, a certain amount of leniency is probably appropriate.

Or, use multiple layers each of which can be handled by different
kinds of programmers.

You can still use regular error handling to handle higher level API violations

> Only Dworkin can answer that question, since it’s his project and he knows why, and for whom, he wrote it. 😊

True enough.  I myself am just making educated guesses.  Those guesses
are, however, based on what felix directly said in past messages.

> Sent from Mail for Windows 10
>
> From: Raymond Jennings
> Sent: Tuesday, June 5, 2018 19:43
> To: All about DGD and Hydra
> Subject: Re: [DGD] Fatal error when no user object returned
>
> 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
>
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd
>
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd