[DGD] Fatal error when no user object returned

Dread Quixadhal quixadhal at gmail.com
Wed Jun 6 05:00:06 CEST 2018 

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?

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.

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.

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

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

More information about the DGD mailing list