Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
Sounds good. But, and call me crazy for asking this, why couldn't sockets be extended to
support such a thing? Must we invent a totally new API?
OLS: A proposal for a new networking API
Posted Jul 23, 2006 11:09 UTC (Sun) by nix (subscriber, #2304)
But fundamentally the BSD sockets API is ugly, quite non-Unixlike, and hard to use and even harder to use correctly, and the thought of using it for *everything* including files is horrible. So no matter what the underlying layer is composed of, we need something better for people to actually *use*. (Ulrich is focused on that, not the implementation details alone: he *is* the libc maintainer.)
The replacement for select() had me cheering. At last, One Inner Loop! :)
Posted Jul 23, 2006 23:58 UTC (Sun) by flewellyn (subscriber, #5047)
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.
Posted Jul 24, 2006 5:47 UTC (Mon) by BrucePerens (guest, #2510)
open("/net/localhost/http", O_RDWR, 0)
Maybe this is not quite what you were asking for :-) . Of course, it's inspired by Plan 9. Using this, or using the socket calls, you get back the same object: a file descriptor. I think socket calls come from BBN's ARPA-sponsored Unix TCP/IP implementation, filtered through Berkeley BSD. They are indeed non-Unix-like, as are the net devices which live in their own unique name space.
Once you get the FD, you can call magic DMA functions on it as Ulrich proposes, which should be valid for plain files, not just network devices. Sometimes, however, what you need to do will fit the simpler sendfile().
Posted Jul 24, 2006 6:59 UTC (Mon) by neilbrown (subscriber, #359)
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
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.
Posted Jul 24, 2006 15:14 UTC (Mon) by mheily (guest, #27123)
fd = open("/net/localhost/ip/192.168.0.1/1023", O_RDWR, 0);
setsockopt(fd, O_TCPSYNCNT, 5);
You could bind to all interfaces by binding to 0.0.0.0 like so:
fd = open("/net/localhost/ip/0.0.0.0/1023", O_RDWR, 0);
Posted Jul 24, 2006 6:15 UTC (Mon) by drag (subscriber, #31333)
In fact there was a group that did a presentation this year at the Usenix conference that did something very odd with computers buses and IP.
Basicly they made the entire computer and all the communication run IP.
Of course it's closed to non-members until next year.. (Is anybody here a member?)
The way things are going pretty soon ethernet networks will be faster then local disk I/O. If latencies decrease along with that, or something like that, then shared memory scemes may start to work.
Distributed operating systems maybe? Or something like treating a small cluster of machines as a single Numa machine with single kernel?
If most IPC stuff uses something that could just as easily be local as network'd then that would make something like that more easily workable. Like how X is mostly network transparent.
er.. or something like that.
Posted Jul 24, 2006 9:39 UTC (Mon) by dlang (✭ supporter ✭, #313)
what they did was to create a pci card that claimed to be a VGA/keyboard/mouse card and remoted that out to another machine via IP (the purpose being to investigate the potential for more 'legacy free' motherboards, including being free of any graphics, keybard, usb, IDE, etc ports)
they found a 40-60% performance hit for doing so, but point out that normal sysadmin tasks don't use these channels so it was deemed acceptable.
while this is a very interesting idea for server manufacturers (and performance can be improved with a custom ASIC instead of the slow FPGA)it's of much less interest for home use (where you don't normally have another machine to serve as the head for your systems, and gamers aren't willing to sacrafice any performance)
while an interesting paper it doesn't seem to be very relavent to the issues being dicussed here.
Posted Jul 24, 2006 10:03 UTC (Mon) by drag (subscriber, #31333)
Thank you. I was curious about what exactly they were talking about.
Posted Aug 4, 2006 5:36 UTC (Fri) by ringerc (subscriber, #3071)
(By the way: I WANT ONE VERY BADLY. I hate the way x86 servers - even Intel server boards etc - can't handle serial console access for POST and BIOS. It's completely retarded, and one area where Sun has been trouncing `PC' servers for years.).
There are also older approaches, such as the `PC Weasel' VGA+keyboard -> serial console cards that've been around for yonks.
That said, you just wrote a summary, so I'm sure there's more in the details.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds