[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Using unix sockets for NSPort
From: |
Richard Frith-Macdonald |
Subject: |
Re: Using unix sockets for NSPort |
Date: |
Fri, 4 Oct 2002 07:13:56 +0100 |
On Thursday, October 3, 2002, at 06:55 pm, Alexander Malmberg wrote:
Hi,
As an experiment (and to try to learn how NSPort works :), I've
implemented basic versions of NSMessagePort and
NSMessagePortNameServer:
http://w1.423.telia.com/~u42308495/alex/unix_sockets-0.1.tar.gz
The patch makes NSMessage* the default port and port name server
classes. It works, although it isn't currently very robust or thread
safe.
NSMessagePort uses unix domain sockets (instead of tcp/ip sockets), and
puts the registered names in {NSTemporaryDirectory()}/ports/ (usually
/tmp/username/ports/). Thus, the ports are private to the user who
created/registered it. The two main advantages with this are:
That's great ... I've long meant to get round to writing unix domain
ports
for better performance when both ends of a connection are on the same
machine.
But I'm not sure that a local port type should be the default port type
...
that would break backward compatibility with OpenStep and all existing
apps -
so we should probably add another compatibility user default to control
this.
1. Security. Nobody else can connect to your services or mess with your
pasteboard. Apps only connect to your ports, so nobody can set up an
evil pasteboard and store everything you cut/copy/select (or change it;
ever pasted something in a terminal?).
It might well make sense to do this ... it would prevent use of
Xterminals
with GNUstep apps, but that might not be important.
2. Several users can run apps on the same system. Currently, only one
user can register a name on a system. With this implementation, each
user gets a private namespace for ports, so they can all run
gdnc/gpbs/apps without any risk of messing things up for some other
user.
I think this makes sense for gpbs/gdnc (with the caveat about
Xterminals)
Not so sure about apps ... Obviously anything wanting to offer general
services would not want to use private single user connections.
This is meant to replace GSTcpPort, but I propose the following
structure for the NSPort/NSPortNameServer classes:
NSMessagePort/NSMessagePortNameServer are private (user- and
system-specific) unix ports, and thus secure
GSPublicMessagePort/GSPublicMessagePortNameServer are public unix ports
(system-specific, but not user-specific) (could be easily implemented
as
a subclass of NSMessagePort)
NSSocketPort/NSSocketPortNameServer are public tcp/ip ports (like the
current GSTcpPort/NSPortNameServer)
NSPort would create NSMessagePort instances, and [NSPortNameServer
+sharedInstance] would return a NSMessagePortNameServer. This way,
everything is secure by default, and those willing to deal with
security
can create and register GSPublicMessagePort:s and NSSocketPort:s
explicitly.
(A useful extension would be an [NSPortNameServer
+unsafeSharedInstance]
method that returned an NSPortNameServer implementation that queried
NSMessagePortNameServer, GSPublicMessagePortNameServer, and
NSSocketPortNameServer, in that order.)
Sounds like a nice overall structure, but I'm not ready to scrap the
existing implementation ... it's robust, efficient, safe. Looking at
your
code I can see a simplifying assumptions made because unix domain
ports are fast and reliable (would be inappropriate for a tcp sockets
port), and no support for threading or timeouts ... so I'd suggest
making
a thread-safe version for local messaging, and making it work
non-blocking
so that a failed remote process won't hang your application.
The company I work for uses many DO processes scattered over several
machines,
many of them running for months at a time ... I wouldn't want to break
that!
So ... my suggestion is -
Add the message port code, but not as the default system.
Create a compatibility user default (stuff for MacOS-X compatibility
already exists
in the base library) to make the message ports the default when in
MacOS-X compatibility mode.
Advertise it a lot ... to get people to turn it on and test it.
Work on threading, non-blocking, timeouts etc.
Add the public version.
Then look at the tcp/ip side - rename GSTcpPort to fit MacOS-X naming,
or write from scratch
based on experience with it and the usix sockets.
Re: Using unix sockets for NSPort, Helge Hess, 2002/10/04
Re: Using unix sockets for NSPort, Alexander Malmberg, 2002/10/04