[DGD] Changing connect() (network package)

[Felix A. Croes]

Shentino <shentino at gmail.com> wrote:

> I was under the impression that any "hooks" for dealing with MP
> specific issues (such as cancellation, rescheduling, committment, and
> whatnot), could simply be stubbed out in SP as no-ops.
>
> By custom event I don't mean event in the DGD style...rather,
> "something happening that DGD doesn't yet know about".  Which would,
> like native I/O, originate from OUTSIDE the driver.  DGD/MP has to
> have SOME way to inject ER's from callouts and user I/O.  Ergo, my
> impression that it could also in some way be extended to deal with
> occurences of my own choosing.

This works in DGD/MP (which knows about threads), but not in DGD
(which doesn't).  It's not something you can solve with an #ifdef.


> Finding out there's actual DGD/MP lingo called "events" further confuses me. B-/

Trying to code your way around my restrictions is your idea; I'm just
walking you through the process.  This step has a solution, but of
course I already know how it's going to end :-)  Let me know when you
want to continue.




Shentino <shentino at gmail.com> wrote:

>[...]
> 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".

A more accurate analogy would be, "this car does not have a builtin
phone, because using a phone in a car increases the probability of
an accident."  If you want to use your own phone in the car I provide,
that's up to you.  If you make a hole in the dashboard to insert your
phone, the warranty is void and you'll have to do your own post-mortem
analysis.


> It makes sense in the case of a
> game that is running on a single server, but what about some sort of
> P2P deal?

In that case, you're going to have those "race condition hell"
problems you mentioned in another context; whatever solution you
come up with here, you can also use there.


> 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.

Once you have to partition your server, you are going to run into
some tough problems.  At that point, optimizing for something this
low-level is ludicrous.


> 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.

One of the most common reasons for partitioning a server is managing
the network load; then you will have something like the external
connection manager in front of <all> user connections.  All of the
big muds with multiple machines per world do this, even if they had
another motive for partitioning.




Shentino <shentino at gmail.com> wrote:

> Oh, just remembered:
>
> Another use of ER injection is the introduction of "itimer" type
> functionality.  I may very well not wish to rely on callouts for this.

Itimer signals interrupt processes, not threads.  Itimers could only
be explicitly supported by expanding the extension interface.  Itimer
signals interrupt system calls and wreak havoc with DGD's internal
design.

I veto itimers.




Shentino <shentino at gmail.com> wrote:

> 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.

This is like Bart's objection to using a one-time password.  An
additional point of failure does not mean an additional vulnerability;
if it is possible to obtain this password with less access than it
would take to obtain a mud admin password, that's where the fault
lies.  In your case, a denial of service attack can be mounted on
any port, not just the one reserved for the external connection
daemon.

The problem and solution are trivial.

Happy New Year, everyone!

Dworkin