I'm curious what a new, socket-replacing API would look like. Keeping in mind that sockets are 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 want 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 now, 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 coming from.
Hmm...now that I think about it, this has potential.
Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds