TCP/IP Sockets in C, Second Edition: Practical Guide for Programmers (The Morgan Kaufmann Practical Guides Series)

196 Pages·2009·0.72 MB·English

by  Michael J. Donahoo

30CorporateDrive,Suite400,Burlington,MA01803,USA
Thisbookisprintedonacid-freepaper.
Copyright©2009byElsevierInc.Allrightsreserved.
Designationsusedbycompaniestodistinguishtheirproductsareoftenclaimedastrademarksor
registeredtrademarks.InallinstancesinwhichMorganKaufmannPublishersisawareofaclaim,the
productnamesappearininitialcapitalorallcapitalletters.Alltrademarksthatappearorareotherwise
referredtointhisworkbelongtotheirrespectiveowners.NeitherMorganKaufmannPublishersnorthe
authorsandothercontributorsofthisworkhaveanyrelationshiporaffiliationwithsuchtrademark
ownersnordosuchtrademarkownersconfirm,endorseorapprovethecontentsofthiswork.Readers,
however,shouldcontacttheappropriatecompaniesformoreinformationregardingtrademarks
andanyrelatedregistrations.
Nopartofthispublicationmaybereproduced,storedinaretrievalsystem,ortransmittedinanyform
orbyanymeans—electronic,mechanical,photocopying,scanning,orotherwise—withoutprior
writtenpermissionofthepublisher.
PermissionsmaybesoughtdirectlyfromElsevier’sScience&TechnologyRightsDepartmentinOxford,
UK:phone:[phone],fax:[phone],E-mail:[e-mail]
alsocompleteyourrequestonlineviatheElsevierhomepage(http://elsevier.com),byselecting
“Support&Contact”then“CopyrightandPermission”andthen“ObtainingPermissions.”
LibraryofCongressCataloging-in-PublicationData
ApplicationSubmitted
ISBN:978-0-12-374540-8
ForinformationonallMorganKaufmannpublications,
visitourWebsiteatwww.mkp.comorwww.elsevierdirect.com
PrintedinTheUnitedStatesofAmerica
09 10 11 12 13 14 15 16 5 4 3 2 1
Preface to the Second Edition
When we wrote the first edition of this book, it was not very common for college courses on
networking to include programming components. That seems difficult to believe now, when
theInternethasbecomesoimportanttoourworld,andthepedagogicalbenefitsofhands-on
programmingandreal-worldprotocolexamplesaresowidelyaccepted.Althoughtherearenow
other languages that provide access to the Internet, interest in the original C-based Berkeley
Sockets remains high. The Sockets API (application programming interface) for networking
was developed at UC Berkeley in the 1980s for the BSD flavor of UNIX—one of the very first
examplesofwhatwouldnowbecalledanopen-sourceproject.
The Sockets API and the Internet both grew up in a world of many competing protocol
families—IPX, Appletalk, DECNet, OSI, and SNA in addition to Transmission Control Proto-
col/InternetProtocal(TCP/IP)—andSocketswasdesignedtosupportthemall.Fewerprotocol
familieswereincommonusebythetimewewrotethefirsteditionofthisbook,andthenum-
ber today is even smaller. Nevertheless, as we predicted in the first edition, the Sockets API
remains important for those who want to design and build distributed applications that use
theInternet—thatis,thatuseTCP/IP.Andtheinterfacehasprovenrobustenoughtosupport
thenewversionoftheInternetProtocol(IPv6),whichisnowsupportedonvirtuallyallcommon
computingplatforms.
Twomainconsiderationsmotivatedthissecondedition.First,basedonourownexperi-
ence and feedback from others, we found that some topics needed to be presented in more
depth and that others needed to be expanded. The second consideration is the increasing
acceptanceanduseofIPversion6,whichisnowsupportedbyessentiallyallcurrentendsys-
templatforms.Atthiswriting,itisnotpossibletouseIPv6toexchangemessageswithalarge
fractionofhostsontheInternet,butitis possibletoassignanIPv6addresstomanyofthem.
AlthoughitisstilltooearlytotellwhetherIPv6willtakeovertheworld,itisnottooearlyto
startwritingapplicationstobeprepared.
ix
x
Preface
Changes from the First Edition
Wehaveupdatedandconsiderablyexpandedmostofthematerial,havingaddedtwochapters.
Majorchangesfromthefirsteditioninclude:
(cid:2) IPversion6coverage.Wenowincludethreekindsofcode:IPv4-specific,IPv6-specific,and
generic. The code in the later chapters is designed to work with either protocol version
ondual-stackmachines.
(cid:2) An additional chapter on socket programming in C++ (contributed by David B. Sturgill).
ThePracticalSocketlibraryprovideswrappersforbasicsocketfunctionality.Theseallow
an instructor to teach socket programming to students without C programming back-
ground by giving them a library and then gradually peeling back the layers. Students
canstartdevelopingimmediatelyafterunderstandingaddresses/portsandclient/server.
Latertheycanbeshownthedetailsofsocketprogrammingbypeekinginsidethewrapper
code.Thoseteachingasubjectthatusesnetworking(e.g.,OS)canusethelibraryandonly
selectivelypeelbackthecover.
(cid:2) Enhancedcoverageofdatarepresentationissuesandstrategiesfororganizingcodethat
sendsandreceivesmessages.Inourinstructionalexperience,wefindthatstudentshave
less and less understanding of how data is actually stored in memory,1 so we have
attempted to compensate with more discussion of this important issue. At the same
time, internationalization will only increase in importance, and thus we have included
basiccoverageofwidecharactersandencodings.
(cid:2) Omission of the reference section. The descriptions of most of the functions that make
up the Sockets API have been collected into the early chapters. However, with so many
onlinesourcesofreferenceinformation—including“manpages”—available,wechoseto
leaveoutthecompletelistingoftheAPIinfavorofmorecodeillustrations.
(cid:2) Highlighting important but subtle facts and caveats. Typographical devices call out
importantconceptsandinformationthatmightotherwisebemissedonfirstreading.
Although the scope of the book has expanded, we have not included everything that
we might have (or even that we were asked to include); examples of topics left for more
comprehensivetexts(orthenextedition)arerawsocketsandprogrammingwithWinSock.
Intended Audience
Weoriginallywrotethisbooksothatwewouldhavesomethingtohandourstudentswhenwe
wantedthemtolearnsocketprogramming,sowewouldnothavetotakeupvaluableclasstime
1WespeculatethatthisisduetothewidespreaduseofC++andJava,whichhidesuchdetailsfromthe
programmer,inundergraduatecurricula.
xi
Preface
teaching it. In the years since the first edition, we have learned a good deal about the topics
that students need lots of help on, and those where they do not need as much handholding.
We also found that our book was appreciated at least as much by practitioners who were
lookingforagentleintroductiontothesubject.Therefore,thisbookisaimedsimultaneously
attwogeneralaudiences:studentsinintroductorycoursesincomputernetworks(graduateor
undergraduate)withaprogrammingcomponent,andpractitionerswhowanttowritetheirown
programsthatcommunicateovertheInternet.Forstudents,itisintendedasasupplement,not
asaprimarytextaboutnetworks.Althoughthissecondeditionissignificantlybiggerinsize
and scope than the first, we hope the book will still be considered a good value in that role.
For practitioners who just want to write some useful code, it should serve as a standalone
introduction—but readers in that category should be warned that this book will not make
themexperts.Ourphilosophyoflearningbydoinghasnotchanged,norhasourapproachof
providingaconcisetutorialsufficienttogetonestartedlearningonone’sown,andleavingthe
comprehensivedetailstootherauthors.Forbothaudiences,ourgoalistotakeyoufarenough
sothatyoucanstartexperimentingandlearningonyourown.
Assumed Background
WeassumebasicprogrammingskillsandexperiencewithCandUNIX.Youareexpectedtobe
conversant with C concepts such as pointers and type casting, and you should have a basic
understanding of the binary representation of data. Some of our examples are factored into
filesthatshouldbecompiledseparately;weassumethatyoucandealwiththat.
Here is a little test: If you can puzzle out what the following code fragment does, you
shouldhavenoproblemwiththecodeinthisbook:
typedef struct {
int a;
short s[2];
} MSG;
MSG *mp, m = {4, 1, 0};
char *fp, *tp;
mp = (MSG *) malloc(sizeof(MSG));
for (fp = (char *)m.s, tp = (char *)mp->s; tp < (char *)(mp+1);)
*tp++ = *fp++;
Ifyoudonotunderstandthisfragment,donotdespair(thereisnothingquitesoconvo-
luted in our code), but you might want to refer to your favorite C programming book to find
outwhatisgoingonhere.
YoushouldalsobefamiliarwiththeUNIXnotionsofprocess/addressspace,command-
line arguments, program termination, and regular file input and output. The material in
Chapters4and6assumesasomewhatmoreadvancedgraspofUNIX.Somepriorexposureto
networkingconceptssuchasprotocols,addresses,clients,andserverswillbehelpful.
xii
Preface
Platform Requirements and Portability
OurpresentationisUNIX-based.Whenweweredevelopingthisbook,severalpeopleurgedus
toincludecodeforWindowsaswellasUNIX.Itwasnotpossibletodosoforvariousreasons,
includingthetargetlength(andprice)wesetforthebook.
ForthosewhoonlyhaveaccesstoWindowsplatforms,pleasenotethattheexamplesin
theearlychaptersrequireminimalmodificationstoworkwithWinSock.(Youhavetochange
the include files and add a setup call at the beginning of the program and a cleanup call
at the end.) Most of the other examples also require very slight additional modifications.
However, some are so dependent on the UNIX programming model that it does not make
sense to port them to WinSock. WinSock-ready versions of the other examples, as well as
detailed descriptions of the code modifications required, are available from the book’s Web
siteatwww.mkp.com/socket.Notealsothatalmostallofourexamplecodeworkswithminimal
modificationsundertheCygwinUNIXlibrarypackageforWindows,whichisavailableonline.
For this second edition, we have adopted the C99 language standard. This version
of the language is supported by most compilers and offers so many readability-improving
advantages—including line-delimited comments, fixed-size integer types, and declarations
anywhereinablock—thatwecouldnotjustifynotusingit.
Our code makes use of the “Basic Socket Interface Extensions for IPv6” ?. Among these
extensions is a new and different interface to the name system. Because we rely completely
onthisnewinterface(getaddrinfo()),ourgenericcodemaynotrunonsomeolderplatforms.
However,weexpectthatmostmodernsystemswillrunourcodejustfine.
Theexampleprogramsincludedherehaveallbeentested(andshouldcompileandrun
withoutmodification)onboth*NIXandMacOS.Header(.h)filelocationsanddependenciesare,
alas,notquitestandardandmayrequiresomefiddlingonyoursystem.Socketoptionsupport
also varies widely across systems; we have tried to focus on those that are most universally
supported. Consult your API documentation for system specifics. (By API documentation we
mean the “man pages” for your system. To learn about this, type “man man” or use your
favoritewebsearchtool.)
Pleasebeawarethatalthoughwestriveforabasiclevelofrobustness,theprimarygoal
ofourcodeexamplesispedagogy,andthecodeisnotproductionquality.Wehavesacrificed
somerobustnessforbrevityandclarity,especiallyinthegenericservercode.(Itturnsoutto
be nontrivial to write a server that works under all combinations of IPv4 and IPv6 protocol
configurations and also maximizes the likelihood of successful client connection under all
circumstances.)
This Book Will Not Make You an Expert!
Wehopethissecondeditionwillbeusefulasaresource,eventothosewhoalreadyknowquite
abitaboutsockets.Aswiththefirstedition,welearnedsomethingsinwritingit.Butbecoming
anexperttakesyearsofexperience,aswellasother,morecomprehensivesources?,?.
xiii
Preface
Thefirstchapterisintendedtogive“justenough”ofthebigpicturetogetyoureadyto
writecode.Chapter??showsyouhowtowriteTCPclientsandserversusingeitherIPv4orIPv6.
Chapter??showshowtomakeyourclientsandserversusethenetwork’snameservice,and
also describes how to make them IP-version-independent. Chapter ?? covers User Datagram
Protocol(UDP).Chapters??and??providebackgroundneededtowritemoreprograms,while
Chapter ?? relates some of what is going on in the Sockets implementation to the API calls;
thesethreeareessentiallyindependentandmaybepresentedinanyorder.Finally,Chapter??
presentsaC++classlibrarythatprovidessimplifiedaccesstosocketfunctionality.
Throughout the book, certain statements are highlighted like this: This book will not
make you an expert! Our goal is to bring to your attention those subtle but important facts
andideasthatonemightmissonfirstreading.Themarksinthemargintellyouto“notewell”
whateverisinbold.
Acknowledgments
Manypeoplecontributedtomakingthisbookareality.Inadditiontoallthosewhohelpedus
withthefirstedition(MichelBarbeau,SteveBernier,ArianDurresi,GaryHarkin,TedHerman,
LeeHollaar,DavidHutchison,ShungeLi,PaulLinton,IvanMarsic,WillisMarti,KihongPark,Dan
Schmitt,MichaelScott,RobertStrader,BenWah,andEllenZegura),weespeciallythankDavid
B.Sturgill,whocontributedcodeandtextforChapter??,andBobbyKrupczakforhishelpin
reviewingthedraftofthissecondedition.Finally,tothefolksatMorganKaufmann/Elsevier—
RickAdams,oureditor,assistanteditorMariaAlonso,andprojectmanagerMelindaRitchie—
thankyouforyourpatience,help,andcaringaboutthequalityofourbook.
Feedback
We are very interested in weeding out errors and otherwise improving future editions/
printings, so if you find any errors, please send an e-mail to either of us. We will maintain
anerratalistonthebook’sWebpage.
[e-mail]
[e-mail]
1
c h a p t e r
Introduction
T
odaypeopleusecomputerstomakephonecalls,watchTV,sendinstantmessagesto
their friends, play games with other people, and buy most anything you can think of—from
songs to automobiles. The ability of programs to communicate over the Internet makes all
this possible. It’s hard to say how many individual computers are now reachable over the
Internet,butwecansafelysaythatitisgrowingrapidly;itwon’tbelongbeforethenumberis
in the billions. Moreover, new applications are being developed every day. With the push for
everincreasingbandwidthandaccess,theimpactoftheInternetwillcontinuetogrowforthe
forseeablefuture.
Howdoesaprogramcommunicatewithanotherprogramoveranetwork?Thegoalofthis
bookistostart youontheroadtounderstandingtheanswertothatquestion,inthecontextof
theCprogramminglanguage.Foralongtime,Cwasthelanguageofchoiceforimplementing
networkcommunicationsoftward.Indeed,theapplicationprogramminginterface(API)known
asSockets wasfirstdevelopedinC.
Before we delve into the details of sockets, however, it is worth taking a brief look at
the big picture of networks and protocols to see where our code will fit in. Our goal here
is not to teach you how networks and TCP/IP work—many fine texts are available for that
purpose [1,3,10,15,17]—butrathertointroducesomebasicconceptsandterminology.
1.1 Networks, Packets, and Protocols
Acomputernetworkconsistsofmachinesinterconnectedbycommunicationchannels.Wecall
thesemachineshostsandrouters.HostsarecomputersthatrunapplicationssuchasyourWeb
1
2
Chapter1:Introduction
browser,yourIMagent,orafile-sharingprogram.Theapplicationprogramsrunningonhosts
arethereal“users”ofthenetwork.Routers(alsocalledgateways)aremachineswhosejobis
torelay,orforward,informationfromonecommunicationchanneltoanother.Theymayrun
programsbuttypicallydonotrunapplicationprograms.Forourpurposes,acommunication
channel is a means of conveying sequences of bytes from one host to another; it may be a
wired(e.g.,Ethernet),awireless(e.g.,WiFi),orotherconnection.
Routers are important simply because it is not practical to connect every host directly
toeveryotherhost.Instead,afewhostsconnecttoarouter,whichconnectstootherrouters,
and so on to form the network. This arrangement lets each machine get by with a relatively
smallnumberofcommunicationchannels;mosthostsneedonlyone.Programsthatexchange
information over the network, however, do not interact directly with routers and generally
remainblissfullyunawareoftheirexistence.
Byinformationwemeansequencesofbytesthatareconstructedandinterpretedbypro-
grams.Inthecontextofcomputernetworks,thesebytesequencesaregenerallycalledpackets.
Apacketcontainscontrolinformationthatthenetworkusestodoitsjobandsometimesalso
includes user data. An example is information identifying the packet’s destination. Routers
usesuchcontrolinformationtofigureouthowtoforwardeachpacket.
A protocol is an agreement about the packets exchanged by communicating programs
and what they mean. A protocol tells how packets are structured—for example, where the
destination information is located in the packet and how big it is—as well as how the infor-
mation is to be interpreted. A protocol is usually designed to solve a specific problem using
givencapabilities.Forexample,theHyperTextTransferProtocol(HTTP) solvestheproblemof
transferringhypertextobjectsbetweenservers,wheretheyarestoredorgenerated,andWeb
browsers that make them visible and useful to users. Instant messaging protocols solve the
problemofenablingtwoormoreuserstoexchangebrieftextmessages.
Implementing a useful network requires solving a large number of different problems.
To keep things manageable and modular, different protocols are designed to solve different
setsofproblems.TCP/IPisonesuchcollectionofsolutions,sometimescalledaprotocolsuite.
IthappenstobethesuiteofprotocolsusedintheInternet,butitcanbeusedinstand-alone
private networks as well. Henceforth when we talk about the network, we mean any network
that uses the TCP/IP protocol suite. The main protocols in the TCP/IP suite are the Internet
Protocol(IP),theTransmissionControlProtocol(TCP),andtheUserDatagramProtocol(UDP).
Itturnsouttobeusefultoorganizeprotocolsintolayers;TCP/IPandvirtuallyallother
protocol suites are organized this way. Figure 1.1 shows the relationships among the proto-
cols, applications, and the Sockets API in the hosts and routers, as well as the flow of data
from one application (using TCP) to another. The boxes labeled TCP and IP represent imple-
mentationsofthoseprotocols.Suchimplementationstypicallyresideintheoperatingsystem
ofahost.ApplicationsaccesstheservicesprovidedbyUDPandTCPthroughtheSocketsAPI,
representedasadashedline.Thearrowdepictstheflowofdatafromtheapplication,through
the TCP and IP implementations, through the network, and back up through the IP and TCP
implementationsattheotherend.
3
1.1Networks,Packets,andProtocols
Application Application
Socket Socket
TCP TCP
IP IP IP
Channel Channel
(e.g., Ethernet)
Host Router Host
Figure1.1: ATCP/IPnetwork.
In TCP/IP, the bottom layer consists of the underlying communication channels—for
example, Ethernet or dial-up modem connections. Those channels are used by the network
layer,whichdealswiththeproblemofforwardingpacketstowardtheirdestination(i.e.,what
routers do). The single-network layer protocol in the TCP/IP suite is the Internet Protocol; it
solves the problem of making the sequence of channels and routers between any two hosts
looklikeasinglehost-to-hostchannel.
TheInternetProtocolprovidesadatagramservice:everypacketishandledanddelivered
bythenetworkindependently,likelettersorparcelssentviathepostalsystem.Tomakethis
work,eachIPpackethastocontaintheaddress ofitsdestination,justaseverypackagethat
youmailisaddressedtosomebody.(We’llsaymoreaboutaddressesshortly.)Althoughmost
deliverycompaniesguaranteedeliveryofapackage,IPisonlyabest-effortprotocol:itattempts
todelivereachpacket,butitcan(andoccasionallydoes)lose,reorder,orduplicatepacketsin
transitthroughthenetwork.
ThelayeraboveIPiscalledthetransportlayer.Itoffersachoicebetweentwoprotocols:
TCP and UDP. Each builds on the service provided by IP, but they do so in different ways to
provide different kinds of transport, which are used by application protocols with different
needs.TCPandUDPhaveonefunctionincommon:addressing.RecallthatIPdeliverspackets
to hosts; clearly, a finer granularity of addressing is needed to get a packet to a particular
applicationprogram,perhapsoneofmanyusingthenetworkonthesamehost.BothTCPand
UDP use addresses, called port numbers, to identify applications within hosts. TCP and UDP
arecalledend-to-endtransportprotocolsbecausetheycarrydataallthewayfromoneprogram
toanother(whereasIPonlycarriesdatafromonehosttoanother).
TCPisdesignedtodetectandrecoverfromthelosses,duplications,andothererrorsthat
mayoccurinthehost-to-hostchannelprovidedbyIP.TCPprovidesareliablebyte-streamchan-
nel, so that applications do not have to deal with these problems. It is a connection-oriented
protocol:beforeusingittocommunicate,twoprogramsmustfirstestablishaTCPconnection,