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.'"
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.
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.
There has been an alternative all the time:
http://en.wikipedia.org/wiki/Transport_Layer_Interface
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.
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.
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.
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.
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.
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
...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.
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.
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.
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.
SJW n. One who posts facts.
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.
Finally! A year of moderation! Ready for 2019?
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?
That explains why - fortunately - it wasn't widely adopted.
All hope abandon ye who enter here.
Well, yeah. When I read the article, my immediate thought was "So, implement your fancy special-purpose socket replacement on top of UDP."
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
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.
Dewey, what part of this looks like authorities should be involved?