Have Sockets Run Their Course? 230
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.'"
whats really needed... (Score:2, Insightful)
is no sockets. some way to seamlessly connect LOCAL processes to each other without socket overhead by using the familiar socket interface. something simpler than shared memory.
and a better protocol method of opening sockets with the hard stuff taken care of by the OS. and with transparent buffer protection etc.
RFC 1925 (Score:5, Insightful)
This seems to dance a bit too close to Networking Truths [faqs.org] 6a, 11, and possibly 12. I will reserve judgment until I see solid real-world evidence.
Re:haha (Score:2, Insightful)
There has been an alternative all the time:
http://en.wikipedia.org/wiki/Transport_Layer_Interface [wikipedia.org]
Hilarious (Score:5, Insightful)
Re:Open Transport, Part II (Score:1, Insightful)
Sorry to burst your bubble, but I remember STREAMS and they sucked. I was also one of the earliest Mac programmers, and frankly, there was little to like in Classic Mac OS either, other than a lot of fiddly and clever hacks to make it fit into 128k.
Yeah, Apple abandoned those technologies because they were tired of fighting alright... fighting their limitations and bugs.
Re:wrong (Score:4, Insightful)
if this were all in one domain, the most flexible and efficient thing would be to have memory for receive frames allocated at the bottom of the stack, and use callbacks all the way up.
because of the user kernel boundary we have a copy which is difficult to get around (put the next 1k bytes exactly here, although i really dont care), and some unfriendly and inefficient hacks to weasel around the 'natural' blocking semantics.
even if its completely academic, i think its interesting to look at the user kernel boundary and try to refactor things which have negative structural impacts.
Re:wrong (Score:5, Insightful)
the most flexible and efficient thing would be to have memory for receive frames allocated at the bottom of the stack, and use callbacks all the way up.
Sure, in the same way that the "most flexible and efficient thing" would be to write inassembly language and turn off the MMU. But UNIX is not trying to do the most flexible and efficient thing, it's trying to be a reasonable tradeoff between simplicity, safety, and efficiency. And that means that efficiency only gets optimized to the point where it stops being a limiting factor for most programs.
Re:Open Transport, Part II (Score:3, Insightful)
Open Transport didn't come about until the mid 1990's.
So, if you were programming for the Classic Mac OS in the 128K days, still doing that 10 years later and hating it *that* much, you probably feel like you've wasted half your life.
Yes, you could have moved on to other, newer, more advanced operating systems, but you *chose* to stick with it. One really has to respect that I suppose.
Shows your more masochistic side.
Re:Really... (Score:5, Insightful)
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 [wikipedia.org]
Re:Hilarious (Score:4, Insightful)
And many these new abstractions as described in the article could be built on top of an OS supplied socket-like API.
It really seems to me... (Score:3, Insightful)
...that most of the things that this guy is talking about would be better implemented below the sockets API. As in, how the OS handles things. Making things transparent is a good thing.
I'll also point out that having a fail over interface so that the client doesn't lose the connection has already been done in OpenBSD's pf called CARP. It is a free alternative to VRRP and HSRP. In other words, this doesn't have to be implemented in the API when another avenue already exists that does it.
Re:wrong (Score:3, Insightful)
but in this case we have structural flaws
Not conforming to someone's pipe dream of kernel design is not a flaw. It's a flaw only if it demonstrably causes problems.
i'm not going to buy into the tablets brought down from the berkeley hills.
That's why they make all kinds. You're free to use Windows Vista; those people spend billions correcting supposed "structural flaws". Don't spoil UNIX or Linux for the rest of us. We like its "structural flaws" the way they are.
Re:Hilarious (Score:1, Insightful)
Twitter seems more .plan than wall... but I agree ;-)
Re:wrong (Score:5, Insightful)
unix has these interfaces as a matter of historical accident, what was an excellent design at the time.
No, UNIX has these interfaces because they get the job done. People tried all sorts of other interfaces and none of them caught on.
you might find that it helps to think about these thing..even when developing important, real-world applications.
How does it "help" me to think about solutions to problems I'm not having? I've never seen the socket interface to be rate limiting in anything I care about.
why shouldn't the kernel be able to call into userspace safely and transfer ownership of a buffer? is that really so terrible to consider?
Well, if that's your biggest itch, be my guest: implement a kernel patch, make it public, convince people to use it, and if it develops a large user community, maybe Linus will pick it up and it will become a standard part of the kernel.
If nobody is willing to put in the effort, evidently the feature isn't needed.
Re:Structured Stream Transport (Score:5, Insightful)
It is said that those who do not understand history are doomed to repeat it...
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.
Byte streams is one of the UNIX fundamantals. Before UNIX, there were many systems which provided wide varieties of structured IO. This turned out to be a real pain and one of the UNIX innovations was simply to scrap it.
Ans today, most applications don't use low level sockets: they cal a library which does it for them. Moving the library in to the kernel is not a good idea.
Re:RFC 1925 (Score:5, Insightful)
Yes, there are always pathological cases that demonstrate the weaknesses of any technique. A big point I take away from RFC1925 (and personal experience), is that you have to A) recognize that trade-offs are always going to be made, and B) adapt your implementation to fit the laws of physics, instead of trying to bend the network to fit what you think an implementation should be.
The simple fact is that Sockets have worked very well for a long time. Yes, this sometimes means you have to shape your design and implementations to fit the "socket style", and history has shown that it is not only possible, but practical. Changing to a new design will not remove the fact that if you design your protocol/app badly, or are inherently in a pathological use-case, then your network performance will suffer.
For some problems, the ssh idea of multiplexing a single socket works well. For others, multiple rsh (*1) style work better. To say that Sockets need to be replaced because you chose to use rsh for your transport is an amazingly arrogant (*2) position. And yes, some of this is "tradition" and inertia, but designing a whole new library should be for significant real-world benefit, and not for corner-cases or maginal 1% gains.
Of course, if someone can actually produce some real-world benchmarks that validate the "let's ditch Sockets" claim...
[*1] As with you, this is totally ignoring the security implications, etc.
[*2] In no way is this a personal attack at you; I mean it in a purely academic sense. It's a very tall claim to say that decades of networking history, and thousands of talented engineers were wrong.
Re:Structured Stream Transport (Score:4, Insightful)
I honestly had never heard of SCTP before, and I'm surprised that it is not used more widely since it has been around since 2000.
Firewalls don't support it. Consumer routers can't do NAT on it. New protocols on the Internet are fairly unlikely to have a chance.
Re:Open Transport, Part II (Score:1, Insightful)
What didn't you like about STREAMS? Was it the nice architectural way you could layer processes or the efficient way you could avoid data copies?
Re:haha (Score:4, Insightful)
That explains why - fortunately - it wasn't widely adopted.
Re:Hilarious (Score:4, Insightful)
Personally I don't use the service, but I'm not sure if I buy a lot of the ideas people have about Twitter (all about ego, vidiots, convergence wackos who want to tack myspace on to your toaster). I'll agree that it is a lot like the .plan updates of old, but deep down it seems more like a hack or set of hacks than a full reimplementation of anything.
Would you rather send out a mass text message, possibly costing your non-text messaging friends hundreds of dollars (those $1/text costs gather pretty quick) or post something on Twitter that he can either look at on his PC or smart phone with unlimited data? Then tinyURL fits in another cheap hack. Sure it makes it easier to fit the URL in your twit (saying that just doesn't feel right), but it also allows Bob to look at that YouTube you sent him at work via redirect. All of this isn't anything new, it is just people coping with changes in the landscape.
Re:Which sockets API? (Score:3, Insightful)
Well, yeah. When I read the article, my immediate thought was "So, implement your fancy special-purpose socket replacement on top of UDP."
Re:Hilarious (Score:4, Insightful)
I'd vote for talk.bizarre.slashdot
Re:Structured Stream Transport (Score:3, Insightful)
Sorry to cut it to you, but NAT is here to stay. As a security paradigm, there's no surface attack to a user's PC that isn't even visible.
If only you could devise some kind of wall between your machine and the fiery flames that didn't require NAT, but alas, such is merely dreaming.