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

Comments

RFC 1925

[Endymion]

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.

Re:RFC 1925

[Endymion]

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.

Hilarious

[karmaflux]

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.

Re:wrong

[jipn4]

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

[shentino]

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

Re:wrong

[jipn4]

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

[serviscope_minor]

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.