[DGD] Changing connect() (network package)

[bart at wotf.org]

On Sat, 29 Dec 2007 19:37:24 -0600, Par Winzell wrote
> On 12/29/07 5:33 PM, Felix A. Croes wrote:
> > As I see it, if you want outgoing connections you can't be too
> > concerned about security.  An external daemon is a good solution
> > for the sake of keeping up with changes in DGD code, not for any
> > other reason.
> 
> This debate is confusing me. I may be missing something here, but... 
> it seems to me you are both avoiding mention of the most persuasive 
> feature of this external daemon idea, namely that it implicitly 
> urges the administrator to export only an extremely limited view of 
> the Internet to DGD.

That is useful in itself, but providing a clean way for making outgoing
connections doesn't stop me from using the OS for such filtering. 

When you are running in an environment where you have a decent level of
control over which users exist on your host, which hosts are directly
connected to your local segment etc, I see many advantages in using a
dedicated communications daemon outside DGD.

I think that that assumption works for somewhat larger environments that can
afford dedicated hosting or do inhouse hosting, and would be very useful for
developing larger scale projects with DGD.

It is however less likely that the typical hobby mud has such an environment,
they often have to deal with shared hosting, and even more often with other
users on the local network segment over which they have no control.

> 
> A mudlib should by and large *not* have the ability to connect to 
> hosts willy-nilly. That is an operating system feature.

So, why shouldn't my mudlib be able to for example pull information from
random web servers and parse it for in-game use?

Someone can send back rubbish, sure. Someone can send rubbish over incomming
connections as well, and many muds allow those from anyone who bothers to try.

> On the other 
> hand, it should not be an entirely passive beast either. Instead, it 
> should be handed a separately and explicitly configured bundle of 
> outbound connections, identified perhaps with opaque strings.

I can see many cases where that would be a really good solution.

> 
> 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. A tight Java daemon in the middle 
> feels just right to me, and it's how I would do it today.

I am using DGD in this role to provide connectivity to an ancient lpmud at the
moment (adding network connectivity to an lpmud 3.x driver? think not..). It
won't scale to thousands of connections, but it needs a fraction of the
resources that a jvm would need :)

But then, that is DGD being used as a general purpose networking tool, not as
game engine, so I guess we agree there.

I think our different views have a bit to do with different kinds of games
that run in different environments.

If a mud implements the intermud 3 protocol including things like mail
exchange, it has to support initiating out of band connections to other muds,
and it won't know beforehand which ones.

If one can dictate the environment, there may well be better solutions for
such things, but right now, thats not really an option for most muds.
Excluding themselves from such connectivity is, and may not be an issue at all
for some, and a major issue for others. The obvious solution is to not build
such muds on DGD, but well, DGD also has some very interesting and desirable
things to offer also.

Bart
--
Created with Open WebMail at http://www.bartsplace.net/
Read my weblog at http://soapbox.bartsplace.net/