LINCOLN
MOFFETT
LBL
AMNES16
LLL
SRI2
SRI51
XEROX STANFORD
TYMSHARE SUMEX
NPS
ACCAT NOSC
AMNES15
NYU
GWC
ANL
UTAH
WPAFB DTI
CORADCOM
RADC CMU
DOCB
MIT44
MIT6
CCA AFGL
RCC5 RCC49
DEC RCC71 BBN40 BBN53
HARVARD
BBN72
STLA
DARCOM
HAWAII
AFSO ISI27
ISI52 RAND
UCLA CIT USC
AFWL
SCOTT
ANDRW
NRL
DCEC
NSA SDAC
MITRE ARPA BRAGG
ROBINS
ABERDEEN
NBS
NORSAR
YUMA
PENTAGON
ISI22
WSMR
COLLINS
GUNTER
EGLIN
LONDON
SATELLI TE CIRCUI T
IMP
TIP
PLURIBUS IMP PLURIBUS TIP C30
TEXAS
(Note: This map does not show ARPA’s experimental satellite connections.)
Names shown are IMP names, not (necessarily) host names.
Source: http://personalpages.manchester.ac.uk/staff/m.dodge/cybergeography/atlas/arpanet4.gif.
connection to the Internet. For one application to another application, the connection was either across a LAN or transiting one or more routers, called IMPs (Internet message passing).
history of sockets 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. One other factor that focused the sockets API down to the client/server model was that the most popular protocol it supported was TCP, which has an inherently 1: 1 communication model.
The sockets API made the client/ server model easy to implement because of the small number of extra system calls that programmers would need to add to their non-networked code so it could take advantage of other computing resources. Although other models are possible, with the sockets API the client/server model is the one that has come to dominate networked computing.
Although the sockets API has more entry points than those shown in Table
table 1: socket aPi systems calls.
socket() bind() listen() accept() connect()
Create a communication endpoint
Bind the endpoint to some set of network-layer parameters Set a limit on the number of outstanding work requests Accept one or more work requests from a client Contact a server to submit a work request
1, it is those five shown that are central to the API and that differentiate it from regular file I/O. In reality the socket() call could have been dropped and replaced with a variant of open(), but this was not done at the time. The socket() and open() calls actually return the same thing to a program: a process-unique file descriptor that is used in all subsequent operations with the API. It is the simplicity of the API that has led to its ubiquity, but that ubiquity has held back the development of alternative or enhanced APIs that could help programmers develop other types of distributed programs.
Client/server computing had many advantages at the time it was developed. It allowed many users to share resources, such as large storage arrays and expensive printing facilities, while keeping these facilities within the control of the same departments that had once run mainframe computing facilities. With this sharing model, it was possible to increase the utilization of what, at the time, were expensive resources.
Three disparate areas of networking are not well served by the sockets API: low-latency or real-time applications; high-bandwidth applications;
References:
http://personalpages.manchester.ac.uk/staff/m.dodge/cybergeography/atlas/arpanet4.gif
Archives