OLS: A proposal for a new networking API
Posted Jul 23, 2006 23:58 UTC (Sun) by flewellyn
In reply to: OLS: A proposal for a new networking API
Parent article: OLS: A proposal for a new networking API
I'm curious what a new, socket-replacing API would look like. Keeping in mind that sockets
more than just "networking", they're "generic IPC", I imagine one improvement would be to
eliminate the distinction between "Unix domain" and "network" sockets. Since currently you have
to specify one or the other, either limiting your application to local connections only, or using a
relatively heavyweight IP or other networking protocol when its overhead wasn't necessary, OR
coding in unpleasant and inelegant conditionals to detect which situation you're in, for each
connection or message.
Yick. It would be really really nice if, instead of having to say "I want local namespace" or "I
internet namespace", you could just tell the kernel "I want a socket", and the kernel would
determine based on the destination of your message what type of internal semantics was
needed. That way, you could code for both local performance and network transparency.
Along with that, I could see real value in adding permissions to sockets themselves. Right
you can get permissions on Unix domain sockets through the filesystem, but internet sockets
don't have that protection. If you could, instead, assign permissions to a socket itself, you could
have a daemon that would only accept connections from certain users, or with certain credentials
such as RSA keys or Kerberos tickets.
Alternatively, imagine making ALL sockets files, including internet domain sockets. Now, a
socket would have a file name, no matter what namespace or protocol you use, and you would
still get the benefit of permissions on the sockets. Plus, instead of using special system calls to
connect with them, all you'd need is calls to open(), read(), write(), and close(). A server program
would just call "makesocket()", which would take parameters for address, protocol, port, and so
on, to create a socket, and then start reading on it (assuming blocking I/O); a client would call
"makesocket()" and then open it to start writing data. The kernel would handle connection
details (if TCP or something else connection-oriented), or else just start sending datagrams (UDP
or something else connectionless) or byte streams (address was for a local socket), and neither
the client nor server programs themselves would need to know or care where the connection was
Hmm...now that I think about it, this has potential.
to post comments)