[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 10:03 PM
Subject: [DGD] Re: Net Security


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


Let me qualify my initial statement(s) - as it relates to socket
programming, I contend that it's poor design to connect multiple protocols
to the same port.  I totally agree that the fundamental constructs of a
language dictate the rather "grey" definition of good programming style.
You addressed this later on, so I won't beat this issue to death. ;)



>Bingo. Something I've considered; why not a 3.2.1-ish ERQ-like scheme for
>implementing sockets?


I, too, think this is a viable option, but for the sake of the argument...
How does this differ from native socket functionality?  You're still giving
John Doe the ability to potentially connect to a remote machine from within
the confines of the MUD.  You said that it could be disabled by "simply not
providing the external process for use" - you could effectly accomplish the
same thing via:

varargs void connect(string sIPNumber, int nPort, string sProtocol)
{
    error("Outgoing socket functionality has been disabled.");
}

in the auto object.  Yes, someone could alter the auto object to get rid of
this block, but I really don't like that rebuttal.  There are ways to
protect against even that: LPC -> C the auto object.  That way, only the
account owner(s) could dictate when actual changes in the auto object became
effective.  Anyway, I'd like to have a native alternative to the networking
package, but it looks I'm going to have to accept that that won't happen.
I'm more intested in alternatives at this point.  Potential alternatives,
anyone? :)


>How about locking
>concepts (semaphores), and the atomicity of calls to kfuns, other objects,
>etc? Inquiring minds are -really- interested. :-)


*shiver*  And I thought I left behind OS programming with the completion of
my OS course. ;)  I, too, am entirely interested in what this would look
like.  The concept of having a this_user() in a multithreaded environment
intrigues me to no end.


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