[DGD] Changing connect() (network package)

[Shentino]

My biggest objection to being forced to do networking OUTSIDE of the
DGD or MP process is the "welcome to race condition hell" passport I'd
need to cross the process boundary.

A single process can have near omnipotent and omniscient power over
what resources it allocates.

But unless I:

A) have only one user on the server,
B) know who's connecting when (requires outgoing anyway in the form of
identd lookups), or
C) do some sort of cryptography (exposes the OTP in the filesystem)
, then using an external daemon is unreliable.

Once the external network daemon is logged in, it would probably be
pretty smooth.

But then again, how do I get it logged in to begin with?  Either I
race as I try to make sure nobody else can log in first, or I play
chicken-egg as I assume I already have one.

I could probably go the xdm route and kill DGD if my net daemon can't
log in and check the server for monogamy.  But it seems messy, and
opens the door to endless-failure loop.

One other thing I need to ask:

What if the mudlib wants to request an action?  It gets sent to the
network daemon, and it handles it.  But what if the daemon can't do
what was asked?  Like, opening a port that happens to be taken, or is
privileged, or otherwise cannot respond?  Now we have the mudlib
having already finished an ER expecting to call certain services
(which were silently redirected outside), only for the supervisor code
getting caught red handed making a promise to the caller it couldn't
keep.

Inside DGD I can check the port synchronously, and properly return an
error if I fail to bind and listen.  But by the time an external
daemon finds out, the mud has already moved on, and may have expected
to use that port.  Simply by handling the request, the underlying
supervisor code made a promise to the caller that the port would be
open.  Breaking that promise could lead to trouble.

By MP's very nature, exec rounds wouldn't be able to successfully
communicate with an external daemon using standard mechanisms AND get
the immediate response that is required to deliver errors when things
go wonky.  I/O only ACTUALLY happens from the point of view of
external stuff once the ER has already committed, at at that point
it's too late to return an error.

I do agree that NATIVE networking code in MP (at least for game
purposes) is a Bad Thing on account of zombie potential.  But
providing hooks and whatnot for an extension to do so is different, as
it places the onus of responsibility on the coder writing the
extension, not that of the coder who wrote the driver.  It's no sin to
invent electricity, even if someone could use it to power a computer
that happens to be controlling a botnet.

Plus, "on demand ER injection" can enable lots more than just plain
networking.  Itimers as well, plus pretty much anything that relies on
external events (by which I mean "stuff that the extension knows will
probably happen but which MP doesn't know about).

Seeing as MP's own code already has to play by certain rules to
maintain apparent serialization (speculative execution), allowing an
extension to do so as well and follow the same rules as MP's own code
already does seems like not a far shot.

I'm not asking for networking to be native.  I'm asking for on-demand
ER injection...preferably without needing to patch the crap out of the
sources.  IMHO, the fact that stuff BESIDES networking can ALSO take
advantage of it only further validates my request.  And even if native
networking is "teh evilness" and should be shunned, I see no need to
let other innocent extensions (like itimers) suffer simply from guilt
by association.