Slashdot Mirror
Have Sockets Run Their Course?
ChelleChelle writes "This article examines the limitations of the sockets API. The Internet and the networking world in general have changed in very significant ways since the sockets API was first developed in 1982, but the API has had the effect of narrowing the ways in which developers think about and write networked applications. This article discusses the history as well as the future of the sockets API, focusing on how 'high bandwidth, low latency, and multihoming are driving the development of new alternatives.'"
You mean like this? http://en.wikipedia.org/wiki/Unix_domain_sockets
Been there, done that. Apple (once again) had a great implementation of an alternative technology, that it finally abandoned when it didn't feel like fighting any more.
Open Transport (the PPC stack used in the Classic Mac OS) was fast, efficient, and cool. And based on the STREAMS methodology, the only real competition to Berkeley Sockets.
Choice is good, mmmkay?
Hire a Linux system administrator, systems engineer,
This seems to dance a bit too close to Networking Truths 6a, 11, and possibly 12. I will reserve judgment until I see solid real-world evidence.
Ce n'est pas une signature automatique.
This guy's worried about "narrowing the ways in which developers think about and write networked applications" in a world where people are reinventing wall(1) as twitter, IRC as friendfeed, and other web 2.0 'innovations.' You want to widen developers' thinking about networking? Leave sockets alone and close off port 80.
REM Old programmers don't die. They just GOSUB without RETURN.
There are Berkeley sockets which are relatively portable, and then there are extremely platform-specific APIs for high performance and scalability. The old API might have run it's course, but most of the new ones are still relevant. Things like asio are helping to merge all the differences into one nice API.
Although the addition of a single system call to a loop would not seem to add much of a burden, this is not the case
Really? For a lot of networking code that's in use these days, I don't see that the system call overhead is the bottleneck. On clients you usually have network bandwidth as the limiting step (rather than system calls). On servers, it usually seems to be disk access or HLL interpreters.
Each system call requires arguments to be marshaled and copied into the kernel, as well as causing the system to block the calling process and schedule another.
That's easy to fix without changing the socket API: just add a system call that can return multiple packets from multiple streams simultaneously, a cross between select and readv. If there's a lot of data buffered in the kernel, it can then return that with a single system call.
Solving this problem requires inverting the communication model between an application and the operating system.
Not only does it not require that, inversion of control doesn't even solve it, since you still have the context switches.
BSD sockets have a limitation of only a single stream at a time (for example, if you are loading a website over HTTP and you get stuck loading a huge image, you have no choice but to open up another socket connection or else wait). They are also stuck around the paradigm of only supporting byte streams, which means that users are always forced to write the same code over and over to create packet headers or delimited messages.
I would highly recommend checking out Structured Stream Transport. I'm not from MIT and I wasn't entirely satisfied with their sample implementation, but the paper is really insightful and explains how you can develop basically a smarter version of TCP that is both more efficient and also more flexible. And I'm sure there are other systems being developed with similar ideas in mind.
We definitely need to keep bsd sockets, if not just because I'm a regular user of netcat :-p, and also because they are what allow the creation of more advanced protocols, but I don't think most applications should still be using such low-level protocols today.
he recently developed SCTP (Stream Control Transport Protocol)4 incorporates support for multihoming at the protocol level, but it is impossible to export this support through the sockets API
The word that bugs me there, is "impossible". The question is, why? If you have to do something with sockets under the hood, then so be it, but it would seem to me that you could just add a few more fields to socket address to take into account multiple homes.
We've already had alternative APIs to sockets and for quite some time. sockets won. There were named pipes, ipx/spx, and the seemingly stupid idea of treating a network resource as a file has trumped every time.
This is my sig.
I am developing SCTP applications and has contributed to the linux implementation, and I think that one of the advantages of the socket API is that it is usable with select()/ and poll(), ie. it is file descriptors you can pass around.
But for SCTP there are things that don't fit nicely into the socket API, especially when using one-to-many socket types. For instance for retrieving options for an association you have to piggyback data in a getsockopt() call by using the output buffer also for input. It works, but it is not nice. Also, for sending/receiving messages you have to use sendmsg/recvmsg with all the features including control data, and the ugly control data parsing.
Really, for networking, all they need to do is ask slashdot's elite technical team. Years before Gmail automatically saved my drafts, /. consistently preempted everone with the above example (or Homeland_Security/FBI/Police knocking on the door, or person getting a hard attack) and snatches the post from the jaws of defeat when the user wouldn't otherwise be able to hit submit. Moreover, unlike anyone else to this day, even gmail, there is also a nice little hint as to the cause of the interruption.
Dealing with network failures isn't actually a trivial issue from the POV of an application, let alone an OS supporting it.
http://en.wikipedia.org/wiki/Two_Generals'_Problem
Or more like this? :)
Rampant carbon sequestration destroyed the Dinosaurs' tropical paradise. I'm here to help repair the damage.
or person getting a hard attack
Viagra overdose?
This is hardly news and partly mistaken.
The statement that sockets limit throughput by copying between kernel and application processes is a bit simplistic. The copy of Rx data to an application usually primes the cache. If data isn't touched and loaded into the cache at this point, it will have to be loaded shortly, anyway. Granted, for Tx this trick does not hold.
Second, the interface is not the implementation. Just because sockets are traditionally implemented as system calls does not state that they have to. User level networking is a well known alternative to OS services for high-bandwidth and low-latency communication (e.g., U-net developed around '96). I know, because I myself built a network stack with large shared buffers that implements the socket API through local function calls (blatant plug, but on topic. The implementation is still shoddy, but good enough for UDP benchmarking).
User level networking can also offers low latency. My implementation doesn't, but U-net does.
This leaves the third point of the article, on multihoming. As sockets abstract away IP addresses and network interfaces, I don't see why they cannot support multihoming behind the socket interface. Note that IP addresses do not have to mapped 1:1 onto NICs. Operating systems generally support load-balancing or fail-over behind the interface through virtual interfaces (in IRIX) or some other means (Netfilter in Linux).
Not need to replace sockets just yet.
The word that bugs me there, is "impossible". The question is, why? If you have to do something with sockets under the hood, then so be it, but it would seem to me that you could just add a few more fields to socket address to take into account multiple homes.
Especially since SCTP actually does use the sockets API. You have to use recvmsg() instead of recv() if you want to do multi-homing, but in using SCTP I was actually impressed by how flexible the BSD socket API actually is. I can't say I particularly like it, and everyone who uses it ends up writing a wrapper around most of the send and recv calls, but flexibility is definitely it's strong point. If we ever do get routing by carrier pigeon, the BSD socket API will be able to adapt to it.
Qxe4
This is not funny. It's called priapism and can result in impotence or worse.
The socket API... or rather the UNIX file descriptor API... has been extended many times. Sockets are already one such extension, and there's no reason you couldn't do something like mmap() a socket to map the buffers into user space directly. Heck, udp sockets already diverge from the read/write paradigm.
The problem with sockets is at a higher level. They're not mapped into the file system name space. You should be able to open a socket by calling open() on something like "/dev/tcp/address-or-name/port-or-name" and completely hide the details of gethostbyname(), bind(), and so on from the application layer. If they'd done that we'd already be using IPv6 for everything because applications wouldn't have to know about the details of addresses because they'd just be arbitrary strings like file names already are.
You mean, like pipes?