[DGD] Re: Net Security

[Jason Cone]

-----Original Message-----
From: Logic <logic at logic.net>
To: Jason Cone <jcone at cs.tamu.edu>; dgd at imaginary.com <dgd at imaginary.com>
Date: Tuesday, March 17, 1998 1:42 AM
Subject: Re: [DGD] Re: Net Security



>[...]
>Really, having multiple protocols on one port isn't that difficult a task,
>[...]


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

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.  The objects that are assigned to those ports are
determined before any data is sent over the connection.  I agree that the
object that is assigned to the port could have an extra layer of abstraction
depending on how the "user" (be it SMTP, FTP, HTTP, etc.) logged in, but I
contend in the same manner as above that that is poor design.  This, of
course, is highly subjective. :)  Even so, you could not sucessfully
implement a FTP server that's capable of running in non-passive mode in this
manner as it's impossible for the MUD to open a data connection with the
remote client.


>You can even go farther, and do HTTP and Gopher this way; it's a damn easy
>way to implement an HTTP server. ;-)


Totally agreed.  Before my knowledge of the net package, I chose to use the
binary port as a HTTP port.  I never have, and never would, consider using
one port for multiple protocols for the reasons outlined above.


>The argument for separation of some tasks is valid in the current LPC
>uni-processing model, since you don't want work on one task to bog down
>others (which can often result in the implementation of MOO-ish forced
>splitting of tasks...blecch). However, when dealing with lightweight
>network services (NNTP, HTTP, SMTP, etc), there's no realistic reason not
>to provide language primitives for implementing it.


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.
:)  This can be prevented to some degree by limiting the size of file
transfers to a minimum, but that's not an ideal solution.  Like you said,
though, the introduction multitheading (which is still planned, I assume)
could change the face of this argument.


--
  Jason H. Cone
  Dept. Computer Science
  Texas A&M University
  jcone at cs.tamu.edu






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