The Artima Developer Community
Sponsored Link

Java Community News
Whither Sockets?

3 replies on 1 page. Most recent reply: Aug 3, 2010 9:54 AM by David Ramsey

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 3 replies on 1 page
Frank Sommers

Posts: 2642
Nickname: fsommers
Registered: Jan, 2002

Whither Sockets? Posted: May 13, 2009 4:34 PM
Reply to this message Reply
Summary
In a recent ACM Queue article, George Neville-Neil writes that the ubiquitous socket API, now almost 30 years old, has not kept up with recent progress in networks, and would need a major overhaul.
Advertisement

Sockets are the primary means of network communication. So much so, writes George Neville-Neil in a recent ACM Queue article, Whither Sockets?, that developers take the limitations of this almost 30-year API for granted:

The sockets API was first released as part of the 4.1c BSD operating system in 1982. While there are longer-lived APIs—for example, those dealing with Unix file I/O—it is quite impressive for an API to have remained in use and largely unchanged for 27 years. The only major update to the sockets API has been the extension of ancillary routines to accommodate the larger addresses used by IPv6.2...

The Internet and the networking world in general have changed in very significant ways since the sockets API was first developed, but in many ways the API has had the effect of narrowing the way in which developers think about and write networked applications.

Neville-Neil explains that expanded network topology, changes in latency and bandwidth, along with the availability of concurrent processing on most systems today would require updates to the Socket API:

The two biggest differences between the networks of 1982 and 2009 are topology and speed... The round-trip time between two machines on a local area network was measured in tens of milliseconds, and between systems over the Internet in hundreds of milliseconds, depending of course on location and the number of hops a packet would be subjected to when being routed between machines... Most computers had a single connection to a local area network; the LAN was connected to a primitive router that might have a few connections to other LANs and a single connection to the Internet.

The popularity of the socket API, says Neville-Neil, resulted in the client-server model emerging as the dominant network programming model:

The model of distributed programming that came to be most popularized by the sockets API was the client/server model, in which there is a server and a set of clients. The clients send messages to the server to ask it to do work on their behalf, wait for the server to do the work requested, and at some later point receive an answer. This model of computing is now so ubiquitous it is often the only model with which many software engineers are familiar. At the time it was designed, however, it was seen as a way of extending the Unix file I/O model over a computer network...

That ubiquity has held back the development of alternative or enhanced APIs that could help programmers develop other types of distributed programs...

The rest of the article explores three areas that, according to Neville-Neil, are not served well by the socket API:

Three disparate areas of networking are not well served by the sockets API: low-latency or realtime applications; high-bandwidth applications; and multihomed systems—that is, those with multiple network interfaces.

Neville-Neil explores proposed solutions to these areas in the concluding section of his article.

Do you agree with Neville-Neil that the socket API is due for an overhaul?


Timothy Brownawell

Posts: 25
Nickname: tbrownaw
Registered: Mar, 2009

Re: Whither Sockets? Posted: May 14, 2009 6:16 AM
Reply to this message Reply
>Do you agree with Neville-Neil that the socket API is due for an overhaul?

Not really.

He doesn't seem to know about epoll or kqueue, POSIX aio, zero-copy network drivers (looks like Linux has been able to do this since at least 2001 for some cards, other OSes would almost certainly have this as well for at least as long), UDP, multicast, the various P2P apps that use -- you guessed it -- TCP and the existing Berkley Sockets API, etc.

Rupert Kittinger-Sereinig

Posts: 21
Nickname: rkit
Registered: Dec, 2005

Re: Whither Sockets? Posted: May 14, 2009 12:06 PM
Reply to this message Reply
I think the most important change did not happen to networks, but to network programmers. A lot of people writing networked software these days will not even know the sockets API, but use some middleware that handles all the "low level" stuff. (The results are not always pretty.)

On the other hand, you can indeed write scalabele, robust, high-throughput, low-latency network software using the socket api and some system-specific extensions like epoll() and sendfile(). But this is far from easy. Obviously, you need a good understanding of the whole software stack involved, good programming skills and good tools. This will not be changed by the introduction of a new API.

David Ramsey

Posts: 34
Nickname: dlramsey
Registered: Apr, 2002

Re: Whither Sockets? Posted: Aug 3, 2010 9:54 AM
Reply to this message Reply
Unless he intends to overthrow the entirety of TCP/IP as the dominant network protocol, I don't see sockets going away any time soon. A connection, in the TCP/IP universe, is a port/IP address pair on each end of the connection.

I could see a new API built on top of sockets that might make P2P programming simpler, or enable wide spread parallel processing of activities via UDP broadcast mechanics. But I am not sure how you replace sockets in the TCP/IP universe as sockets are just a logical abstraction of the 4 pieces of information that define a TCP connection.

Even UDP is not that much different. Years ago when we wanted to use UDP for a network product that needed more than 64K ports, we coded it over UDP and then added another layer that basically emulated TCP by prioritizing, reassembling, and retransmitting packets to ensure reliable delivery.

Like I said, I can see some new API built on top of sockets maybe taking off and assisting programmers but I can't see it replacing sockets.

Of course, maybe my imagination is just too limited but I'd certainly need to be convinced rather than just told.

Flat View: This topic has 3 replies on 1 page
Topic: Acegi and J2EE Security Previous Topic   Next Topic Topic: Directly executing Java bytecodes versus JITing on a RISC


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2018 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use