ARPANET GEOGRAPHIC MAP, OCTOBER 1980
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;