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:Hilarious

[Darinbob]

And many these new abstractions as described in the article could be built on top of an OS supplied socket-like API.

Re:Hilarious

[Steauengeglase]

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:Hilarious

[An ominous Cow art]

I'd vote for talk.bizarre.slashdot

Re:wrong

[convolvatron]

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

[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:Open Transport, Part II

[Anonymous Coward]

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

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

Re:Structured Stream Transport

[amorsen]

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:haha

[ThePhilips]

... TLI is designed from an OSI model-oriented viewpoint ...

That explains why - fortunately - it wasn't widely adopted.