[DGD] Re: Net Security

[Logic]

On Tue, 17 Mar 1998, Jason Cone wrote:
> Careful. ;)  I didn't say that it couldn't be done.  I totally agree with
> you in that it'd be a fairly easy task, but I will contend until the day
> that I die that having multiple protocols connect to the same port is poor
> design.

I've actually stopped making arguments about "good design" these days; it
is generally the language facilities that determine what good design in
that language really is.

For example, what would be considered good design in LPC can often look
atrocious in Perl (and vice-versa).

> Even if you develop your own architecture to handle multiple protocols
> on the same port, there will be some packets that will work only for one
> protocol and not the other - that is the basis for my argument on the
> poor design.

My argument should have been aimed more at the implementation of protocols
for communicating with external processes instead of traditional services
like HTTP or FTP. After two or three protocols, the design starts looking
pretty ugly.

However, in the scope of what the language permits, this is the best
possible design available. Three approaches are possible in this
situation:

a) continue layering protocols on a single port, until they all start
   tromping all over each other. ;-)

b) choose another language to implement the design in (this could involve
   doing what is needed in an external system, hooked into the existing
   design using facilities that are available, if possible).

c) extend the language you're currently using to support what you need to
   do.

I think we've both targetted c).

> To be more specific, though, (and correct me if I'm wrong) without the
> networking package DGD can only open two ports - a "MUD" port and an
> alternative binary port.

Bingo. Something I've considered; why not a 3.2.1-ish ERQ-like scheme for
implementing sockets? Essentially, you have a fixed protocol for talking
to a single external process. This external process can do whatever you
want, including networking. The ability to infinitely extend the server
(outside of the server) is now available (and easily disablable by simply
not providing the external process for use), and done generically instead
of building these kinds of things into the language.

An object within the mud could manage communication with that external
system, and probably provide much the same functionality already provided
by the net package.

Mind you, this type of scheme has it's own security hurdles to overcome.
;-)

> This is an entirely valid argument and one that I must submit to.  I also
> think that most file transfers that take place via FTP and/or HTTP for
> MUdlib purposes are relatively small.  I'd personally kill the bloody fool
> that decided to upload a 5 MByte file to the MUD with the LPC FTP server.

Unless the -system's- FTP server is a DGD driver. Along with an integrated
HTTP server, SMTP server, etc. Think of the ease of integration of these
kinds of services in an LPC server. :-) This is the place where
multithreading would -really- shine.

To Dworkin, on that subject: do you have a preliminary concept of what
your threaded LPC will look like? Will the LPC programmer see much of
this, or will a lot of it be hidden behind the scenes? How about locking
concepts (semaphores), and the atomicity of calls to kfuns, other objects,
etc? Inquiring minds are -really- interested. :-)

-- 
  _ ____ ____________________________________________________________________
 / /___/\__                                                                  \
/  \   \ \/\  logic at logic.net                                                 \
\   \   \  /  http://www.logic.net/~logic/                                    /
 \___\___\/__________________________________________________________________/





List config page:  http://list.imaginary.com/mailman/listinfo/dgd