[DGD] Changing connect() (network package)

[Shentino]

Wow...what a feud :)

My two cents:

Networking package is just one of many possible things that could make
use of custom events that may profit from ER injection into MP.

As far as "boo on net package", all of Dworkin's arguments are true,
however, an external daemon may cause the same problems.  And here, we
have some arbitrary "3rd party code" that isn't even benefiting from
the same coding expertise that went into DGD & DGD/MP in the first
place.

Also, handling ANYTHING outside of DGD introduces overhead in the form
of maintenance, signalling, context switching, and you have yet
another process competing with DGD for the attention of the OS.  You
now have TWO queues that can backlog, instead of just one, for every
connection.  With an external "network daemon" it has to deal with I/O
with the external world.  THEN it must also relay to and fro with DGD
itself, which itself introduces networking overhead, even if it's just
from localhost to localhost.

As far as the "solution" being "outlaw outbound connections", it's
pretty much the same thing as saying "nobody should drive a car
because you could run someone over".  It makes sense in the case of a
game that is running on a single server, but what about some sort of
P2P deal?

At any rate, DGD lends itself quite easily to purposes OTHER than
games.  Heck, didn't iChat use it to capture like 80 percent of the
market in only 6 months or so?  If I were of a mind to, DGD with
networking capabilities could make a very kick-arse IRCd.

Just for kicks, here's a game scenario that COULD benefit from networking:

Say you have a ginormous world that's so friggin huge it has to be
split between multiple servers (or VMs).  With each server handling a
certain geographical section, it could be somewhat manageable to run
the entire world.  Proper synchronization when stuff crosses zone
boundaries may very well require objects to be marshalled from one
server to another, and simple native networking API is probably the
most efficient, and safest, way to do that.

Using an external daemon for this could at best introduce massive
overhead in the form of doing nothing but being a redirector.
Networking code that resides in the DGD (or DGD/MP) process can do a
MUCH better job.

But in the general case, a network interface for DGD would be quite useful.

And if that's not enough, there are plenty of other things besides
networking that could benefit from arbitrary injection of ER's.  Such
as an asynchronous "reset" interface, or perhaps a "cleanup" mechanism
that goes around firing off garbage collection.

My point is that while coding networking itself directly into DGD /
DGDMP may be hazardous, simply introducing a generic interface for ER
injection, PLUS a way for extensions to inform DGD "hey something just
happened and I need to start an ER now" would make it easier to do
many things, and in the case of the network package, it would be lots
cleaner to not have to patch any DGD/MP code to get functionality.

And no actual networking code would need to appear in MP if we could
define our own custom events...

Perhaps in response to a SIGIO on one of the ports my extension has
opened could set some sort of "extension stuff pending" flag, and
DGD/MP would call back into my extension to service the flag.  My code
would then say "start this exec round".  And at that point, it would
be a plain ER on the same level as callouts and native I/O, with any
special handling for cancellation, committment, rescheduling, and
whatnot simply redirected back to my extension which would handle them
appropriately.  Sorta like my extension would "raise an interrupt" to
MP, which woudl be serviced with a callback.

struct custom_event {
   void (*commit_ok_callback)(blah); /* if the exec round we tried to
inject committed OK */
   void (*commit_fail_callback)(blah);/* if the exec round we tried to
inject was NOT committed */
}

int add_custom_event(struct custom_event *info);

void inject_exec_round(DGD_OBJECT, blah args, blah function_name,
DGD_EVENT er_type).

In this example (there may be better ways to implement), whenever I
want to tell DGD to do an exec round for me, I simply call the
injection function, and DGD then takes care of it in the same way as
it would with any other ER it would be handling.

I'm assuming, of course, that once an ER is underway, it's given the
same treatment no matter how it was started...at least as far as LPC
calls and interfacing with the kfuns and whatnot.

If MP's own code were to use this, I suppose it would go like this:

when an incoming connection is committed, MP simply is happy that LPC
was notified, and moves on
when an incoming connection is NOT committed, MP simply tries again
later, unless in the meantime it has closed, in which case MP simply
pretends it never came in at all.

when new input commits, MP injects an ER for the next piece of data in
the user's queue
when new input fails to commit, MP tries again.

when a callout commits, MP dequeues it from both the object it started
in, as well as the master callout table
when a callout fails to commit, MP tries again if the callout still exists.

And for my own code:

when a port open commits, EXT marks the socket listen as complete
when a port open fails to commit, EXT tries again if the port is still open

when new input commits, EXT

For MP's own handling of its own events, those are just guesses.  By
an operation committing, I mean the ER started for LPC side
notification successfully ran, and its state was successfully
committed to the base plane.  Sorta like an atomic function returning
normally.  And by failing, I mean that the ER started for the purpose
of LPC notification didn't quite commit.

Simply monopolizing ER injection and reserving it for MP's own
internal use excludes much MUCH more than just networking.

If Dworkin were to provide a generic event interface to MP, adding
networking would be much easier, as would many other things.  And best
of all, Dworkin wouldn't even need to code one BIT of networking
functionality into DGD.  With the right hooks, my extension could take
care of everything.

On Dec 29, 2007 10:22 PM,  <bart at wotf.org> wrote:
> On Sat, 29 Dec 2007 19:37:24 -0600, Par Winzell wrote
> >
> > In the past I've argued with some force for a general network
> > package in DGD. I still think it's very useful for all those times
> > when we wish to use DGD not as a game engine, but as a programming environment.
> >
> > But I've changed my mind when it comes to hosting games. There is no
> > good reason to include the full power of a general purpose
> > networking API in a game engine.
>
> Was thinking some more about this, and I think we agree on this in concept,
> but not on what it means.
>
> To me, a lib implemented on top of DGD is at the very least split into a
> kernel and a game lib, possibly with a layer inbetween (called system in my
> case, System in case of the kernel lib I believe). While I don't use the
> kernel lib, I follow that same general setup.
>
> The 'game engine' to me is the game lib, ie, the part that runs on top of the
> system lib or the kernel. This part imho should not have a general purpose
> networking api, and should not have outgoing networking connectivity at all,
> rather, when it need things that would require such privileges, it will have
> to ask the system or kernel for it.
>
> This doesn't mean to me however that the kernel couldn't be provided with a
> general purpose networking api by the driver, and then restrict it to what is
> needed for the game engine.
>
> Bart.
> --
> Created with Open WebMail at http://www.bartsplace.net/
> Read my weblog at http://soapbox.bartsplace.net/
>
> ___________________________________________
>
> https://mail.dworkin.nl/mailman/listinfo/dgd
>