OLS: A proposal for a new networking API

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

The (a) problem with
   open("/net/localhost/http", O_RDWR, 0)
type approaches is that they combine "socket" and "connect" into one
call, and so there is no room for doing anything in between like bind
or setsockopt.  Those things aren't always needed, but sometimes they are.

You could try
  open("/net/local/http:bind=1023;sourceaddr=xx.xx.xx.xx;tcp_syncnt=5")
but I don't think you would get very far.

Unfortunately IPC is simply very different from for file IO and trying
to use the same API will be a problem.  Having an open_url library call
is about the best you can do.