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;