A4.2BSDInterprocessCommunicationPrimer DRAFTof8April1993 SamuelJ.Leffler RobertS.Fabry WilliamN.Joy ComputerSystemsResearchGroup DepartmentofElectricalEngineeringandComputerScience UniversityofCalifornia,Berkeley Berkeley,California94720 (415)642-7780 ABSTRACT Thisdocumentprovidesanintroductiontotheinterprocesscommunication facilitiesincludedinthe4.2BSDreleaseoftheVAX*UNIX**system. Itdiscussestheoverallmodelforinterprocesscommunicationandintroducestheinterprocesscommunicationprimitiveswhichhavebeenaddedtothe system.Themajorityofthedocumentconsiderstheuseoftheseprimitivesin developingapplications.ThereaderisexpectedtobefamiliarwiththeCprogramminglanguageasallexamplesarewritteninC. *DECandVAXaretrademarksofDigitalEquipmentCorporation. **UNIXisaTrademarkofBellLaboratories.

4.2BSDIPCPrimer -2- Introduction 1.INTRODUCTION Oneofthemostimportantpartsof4.2BSDistheinterprocesscommunicationfacilities.These facilitiesaretheresultofmorethantwoyearsofdiscussionandresearch.Thefacilitiesprovided in4.2BSDincorporatemanyoftheideasfromcurrentresearch,whiletryingtomaintainthe UNIXphilosophyofsimplicityandconciseness.Itishopedthattheinterprocesscommunication facilitiesincludedin4.2BSDwillestablishastandardforUNIX.Fromtheresponsetothedesign, itappearsmanyorganizationscarryingoutworkwithUNIXareadoptingit. UNIXhaspreviouslybeenveryweakintheareaofinterprocesscommunication.Priorto the4.2BSDfacilities,theonlystandardmechanismwhichallowedtwoprocessestocommunicate werepipes(thempxfileswhichwerepartofVersion7wereexperimental).Unfortunately,pipes areveryrestrictiveinthatthetwocommunicatingprocessesmustberelatedthroughacommon ancestor.Further,thesemanticsofpipesmakesthemalmostimpossibletomaintaininadistributedenvironment. EarlierattemptsatextendingtheipcfacilitiesofUNIXhavemetwithmixedreaction.The majorityoftheproblemshavebeenrelatedtothefactthesefacilitieshavebeentiedtotheUNIX filesystem;eitherthroughnaming,orimplementation.Consequently,theipcfacilitiesprovidedin 4.2BSDhavebeendesignedasatotallyindependentsubsystem.The4.2BSDipcallowsprocesses torendezvousinmanyways.ProcessesmayrendezvousthroughaUNIXfilesystem-likename space(aspacewhereallnamesarepathnames)aswellasthroughanetworknamespace.In fact,newnamespacesmaybeaddedatafuturetimewithonlyminorchangesvisibletousers. Further,thecommunicationfacilitieshavebeenextendedtoincludedmorethanthesimplebyte streamprovidedbyapipe-likeentity.Theseextensionshaveresultedinacompletelynewpartof thesystemwhichuserswillneedtimetofamiliarizethemselveswith.Itislikelythatasmoreuse ismadeofthesefacilitiestheywillberefined;onlytimewilltell. Theremainderofthisdocumentisorganizedinfoursections.Section2introducesthenew systemcallsandthebasicmodelofcommunication.Section3describessomeofthesupporting libraryroutinesusersmayfindusefulinconstructingdistributedapplications.Section4isconcernedwiththeclient/servermodelusedindevelopingapplicationsandincludesexamplesofthe twomajortypesofservers.Section5delvesintoadvancedtopicswhichsophisticatedusersare likelytoencounterwhenusingtheipcfacilities. DRAFTof8April1993 Leffler/Fabry/Joy 4.2BSDIPCPrimer -3- Basics 2.BASICS Thebasicbuildingblockforcommunicationisthesocket.Asocketisanendpointofcommunicationtowhichanamemaybebound.Eachsocketinusehasatypeandoneormoreassociatedprocesses.Socketsexistwithincommunicationdomains.Acommunicationdomainisan abstractionintroducedtobundlecommonpropertiesofprocessescommunicatingthroughsockets. Onesuchpropertyistheschemeusedtonamesockets.Forexample,intheUNIXcommunication domainsocketsarenamedwithUNIXpathnames;e.g.asocketmaybenamed‘‘/dev/foo’’. Socketsnormallyexchangedataonlywithsocketsinthesamedomain(itmaybepossibletocross domainboundaries,butonlyifsometranslationprocessisperformed).The4.2BSDipcsupports twoseparatecommunicationdomains:theUNIXdomain,andtheInternetdomainisusedbyprocesseswhichcommunicateusingthetheDARPAstandardcommunicationprotocols.Theunderlyingcommunicationfacilitiesprovidedbythesedomainshaveasignificantinfluenceontheinternalsystemimplementationaswellastheinterfacetosocketfacilitiesavailabletoauser.An exampleofthelatteristhatasocket‘‘operating’’intheUNIXdomainseesasubsetofthepossibleerrorconditionswhicharepossiblewhenoperatingintheInternetdomain. 0.1.Sockettypes Socketsaretypedaccordingtothecommunicationpropertiesvisibletoauser.Processesare presumedtocommunicateonlybetweensocketsofthesametype,althoughthereisnothingthat preventscommunicationbetweensocketsofdifferenttypesshouldtheunderlyingcommunication protocolssupportthis. Threetypesofsocketscurrentlyareavailabletoauser.Astreamsocketprovidesforthe bidirectional,reliable,sequenced,andunduplicatedflowofdatawithoutrecordboundaries.Aside fromthebidirectionalityofdataflow,apairofconnectedstreamsocketsprovidesaninterface nearlyidenticaltothatofpipes*. Adatagramsocketsupportsbidirectionalflowofdatawhichisnotpromisedtobe sequenced,reliable,orunduplicated.Thatis,aprocessreceivingmessagesonadatagramsocket mayfindmessagesduplicated,and,possibly,inanorderdifferentfromtheorderinwhichitwas sent.Animportantcharacteristicofadatagramsocketisthatrecordboundariesindataarepreserved.Datagramsocketscloselymodelthefacilitiesfoundinmanycontemporarypacket switchednetworkssuchastheEthernet. Arawsocketprovidesusersaccesstotheunderlyingcommunicationprotocolswhichsupport socketabstractions.Thesesocketsarenormallydatagramoriented,thoughtheirexactcharacteristicsaredependentontheinterfaceprovidedbytheprotocol.Rawsocketsarenotintendedfor thegeneraluser;theyhavebeenprovidedmainlyforthoseinterestedindevelopingnewcommunicationprotocols,orforgainingaccesstosomeofthemoreesotericfacilitiesofanexistingprotocol.Theuseofrawsocketsisconsideredinsection5. Twopotentialsockettypeswhichhaveinterestingpropertiesarethesequencedpacketsocket andthereliablydeliveredmessagesocket.Asequencedpacketsocketisidenticaltoastream socketwiththeexceptionthatrecordboundariesarepreserved.Thisinterfaceisverysimilarto thatprovidedbytheXeroxNSSequencedPacketprotocol.Thereliablydeliveredmessagesocket hassimilarpropertiestoadatagramsocket,butwithreliabledelivery.Whilethesetwosocket typeshavebeenlooselydefined,theyarecurrentlyunimplementedin4.2BSD.Assuch,inthis documentwewillconcernourselvesonlywiththethreesockettypesforwhichsupportexists. 0.2.Socketcreation Tocreateasocketthesocketsystemcallisused: *IntheUNIXdomain,infact,thesemanticsareidenticaland,asonemightexpect,pipeshavebeen implementedinternallyassimplyapairofconnectedstreamsockets. DRAFTof8April1993 Leffler/Fabry/Joy 4.2BSDIPCPrimer -4- Basics s=socket(domain,type,protocol); Thiscallrequeststhatthesystemcreateasocketinthespecifieddomainandofthespecifiedtype. Aparticularprotocolmayalsoberequested.Iftheprotocolisleftunspecified(avalueof0),the systemwillselectanappropriateprotocolfromthoseprotocolswhichcomprisethecommunication domainandwhichmaybeusedtosupporttherequestedsockettype.Theuserisreturneda descriptor(asmallintegernumber)whichmaybeusedinlatersystemcallswhichoperateon sockets.Thedomainisspecifiedasoneofthemanifestconstantsdefinedinthefile <sys/socket.h>.FortheUNIXdomaintheconstantisAFUNIX*;fortheInternetdomain AFINET.ThesockettypesarealsodefinedinthisfileandoneofSOCKSTREAM, SOCKDGRAM,orSOCKRAWmustbespecified.TocreateastreamsocketintheInternet domainthefollowingcallmightbeused: s=socket(AFINET,SOCKSTREAM,0); ThiscallwouldresultinastreamsocketbeingcreatedwiththeTCPprotocolprovidingthe underlyingcommunicationsupport.Tocreateadatagramsocketforon-machineuseasamplecall mightbe: s=socket(AFUNIX,SOCKDGRAM,0); Toobtainaparticularprotocoloneselectstheprotocolnumber,asdefinedwithinthecommunicationdomain.FortheInternetdomaintheavailableprotocolsaredefinedin <netinet/in.h>or,betteryet,onemayuseoneofthelibraryroutinesdiscussedinsection3,such asgetprotobyname: #include<sys/types.h> #include<sys/socket.h> #include<netinet/in.h> #include<netdb.h> ... pp=getprotobyname("tcp"); s=socket(AFINET,SOCKSTREAM,pp->pproto); Thereareseveralreasonsasocketcallmayfail.Asidefromtherareoccurrenceoflackof memory(ENOBUFS),asocketrequestmayfailduetoarequestforanunknownprotocol (EPROTONOSUPPORT),orarequestforatypeofsocketforwhichthereisnosupportingprotocol(EPROTOTYPE). 0.3.Bindingnames Asocketiscreatedwithoutaname.Untilanameisboundtoasocket,processeshaveno waytoreferenceitand,consequently,nomessagesmaybereceivedonit.Thebindcallisusedto assignanametoasocket: bind(s,name,namelen); Theboundnameisavariablelengthbytestringwhichisinterpretedbythesupportingprotocol(s).Itsinterpretationmayvaryfromcommunicationdomaintocommunicationdomain(thisis oneofthepropertieswhichcomprisethe‘‘domain’’).IntheUNIXdomainnamesarepathnames whileintheInternetdomainnamescontainanInternetaddressandportnumber.Ifonewanted tobindthename‘‘/dev/foo’’toaUNIXdomainsocket,thefollowingwouldbeused: bind(s,"/dev/foo",sizeof("/dev/foo")−1); (Notehowthenullbyteinthenameisnotcountedaspartofthename.)InbindinganInternet addressthingsbecomemorecomplicated.Theactualcallissimple, *ThemanifestconstantsarenamedAFwhateverastheyindicatethe‘‘addressformat’’tousein interpretingnames. DRAFTof8April1993 Leffler/Fabry/Joy 4.2BSDIPCPrimer -5- Basics #include<sys/types.h> #include<netinet/in.h> ... structsockaddrinsin; ... bind(s,&sin,sizeof(sin)); buttheselectionofwhattoplaceintheaddresssinrequiressomediscussion.Wewillcomeback totheproblemofformulatingInternetaddressesinsection3whenthelibraryroutinesusedin nameresolutionarediscussed. 0.4.Connectionestablishment Withaboundsocketitispossibletorendezvouswithanunrelatedprocess.Thisoperation isusuallyasymmetricwithoneprocessa‘‘client’’andtheothera‘‘server’’.Theclientrequests servicesfromtheserverbyinitiatinga‘‘connection’’totheserver’ssocket.Theserver,whenwillingtoofferitsadvertisedservices,passively‘‘listens’’onitssocket.Ontheclientsidetheconnect callisusedtoinitiateaconnection.UsingtheUNIXdomain,thismightappearas, connect(s,"server-name",sizeof("server-name")); whileintheInternetdomain, structsockaddrinserver; connect(s,&server,sizeof(server)); Iftheclientprocess’ssocketisunboundatthetimeoftheconnectcall,thesystemwillautomaticallyselectandbindanametothesocket;c.f.section5.4.Anerrorisreturnedwhentheconnectionwasunsuccessful(anynameautomaticallyboundbythesystem,however,remains).Otherwise,thesocketisassociatedwiththeserveranddatatransfermaybegin. Manyerrorscanbereturnedwhenaconnectionattemptfails.Themostcommonare: ETIMEDOUT Afterfailingtoestablishaconnectionforaperiodoftime,thesystemdecidedtherewasno pointinretryingtheconnectionattemptanymore.Thisusuallyoccursbecausethedestinationhostisdown,orbecauseproblemsinthenetworkresultedintransmissionsbeinglost. ECONNREFUSED Thehostrefusedserviceforsomereason.Whenconnectingtoahostrunning4.2BSDthisis usuallyduetoaserverprocessnotbeingpresentattherequestedname. ENETDOWNorEHOSTDOWN Theseoperationalerrorsarereturnedbasedonstatusinformationdeliveredtotheclient hostbytheunderlyingcommunicationservices. ENETUNREACHorEHOSTUNREACH Theseoperationalerrorscanoccureitherbecausethenetworkorhostisunknown(noroute tothenetworkorhostispresent),orbecauseofstatusinformationreturnedbyintermediate gatewaysorswitchingnodes.Manytimesthestatusreturnedisnotsufficienttodistinguish anetworkbeingdownfromahostbeingdown.Inthesecasesthesystemisconservative andindicatestheentirenetworkisunreachable. Fortheservertoreceiveaclient’sconnectionitmustperformtwostepsafterbindingits socket.Thefirstistoindicateawillingnesstolistenforincomingconnectionrequests: listen(s,5); Thesecondparametertothelistencallspecifiesthemaximumnumberofoutstandingconnections whichmaybequeuedawaitingacceptancebytheserverprocess.Shouldaconnectionbe requestedwhilethequeueisfull,theconnectionwillnotberefused,butrathertheindividual messageswhichcomprisetherequestwillbeignored.Thisgivesaharriedservertimetomake roominitspendingconnectionqueuewhiletheclientretriestheconnectionrequest.Hadthe DRAFTof8April1993 Leffler/Fabry/Joy 4.2BSDIPCPrimer -6- Basics connectionbeenreturnedwiththeECONNREFUSEDerror,theclientwouldbeunabletotellif theserverwasupornot.AsitisnowitisstillpossibletogettheETIMEDOUTerrorback, thoughthisisunlikely.Thebacklogfiguresuppliedwiththelistencallislimitedbythesystemto amaximumof5pendingconnectionsonanyonequeue.Thisavoidstheproblemofprocesses hoggingsystemresourcesbysettinganinfinitebacklog,thenignoringallconnectionrequests. Withasocketmarkedaslistening,aservermayacceptaconnection: fromlen=sizeof(from); snew=accept(s,&from,&fromlen); Anewdescriptorisreturnedonreceiptofaconnection(alongwithanewsocket).Iftheserver wishestofindoutwhoitsclientis,itmaysupplyabufferfortheclientsocket’sname.Thevalueresultparameterfromlenisinitializedbytheservertoindicatehowmuchspaceisassociatedwith from,thenmodifiedonreturntoreflectthetruesizeofthename.Iftheclient’snameisnotof interest,thesecondparametermaybezero. Acceptnormallyblocks.Thatis,thecalltoacceptwillnotreturnuntilaconnectionis availableorthesystemcallisinterruptedbyasignaltotheprocess.Further,thereisnowayfor aprocesstoindicateitwillacceptconnectionsfromonlyaspecificindividual,orindividuals.Itis uptotheuserprocesstoconsiderwhotheconnectionisfromandclosedowntheconnectionifit doesnotwishtospeaktotheprocess.Iftheserverprocesswantstoacceptconnectionsonmore thanonesocket,ornotblockontheacceptcalltherearealternatives;theywillbeconsideredin section5. 0.5.Datatransfer Withaconnectionestablished,datamaybegintoflow.Tosendandreceivedatathereare anumberofpossiblecalls.Withthepeerentityateachendofaconnectionanchored,ausercan sendorreceiveamessagewithoutspecifyingthepeer.Asonemightexpect,inthiscase,thenthe normalreadandwritesystemcallsareuseable, write(s,buf,sizeof(buf)); read(s,buf,sizeof(buf)); Inadditiontoreadandwrite,thenewcallssendandrecvmaybeused: send(s,buf,sizeof(buf),flags); recv(s,buf,sizeof(buf),flags); Whilesendandrecvarevirtuallyidenticaltoreadandwrite,theextraflagsargumentisimportant.Theflagsmaybespecifiedasanon-zerovalueifoneormoreofthefollowingisrequired: SOFOOBsend/receiveoutofbanddata SOFPREVIEWlookatdatawithoutreading SOFDONTROUTEsenddatawithoutroutingpackets Outofbanddataisanotionspecifictostreamsockets,andonewhichwewillnotimmediately consider.Theoptiontohavedatasentwithoutroutingappliedtotheoutgoingpacketsiscurrentlyusedonlybytheroutingtablemanagementprocess,andisunlikelytobeofinteresttothe casualuser.Theabilitytopreviewdatais,however,ofinterest.WhenSOFPREVIEWisspecifiedwitharecvcall,anydatapresentisreturnedtotheuser,buttreatedasstill‘‘unread’’.That is,thenextreadorrecvcallappliedtothesocketwillreturnthedatapreviouslypreviewed. 0.6.Discardingsockets Onceasocketisnolongerofinterest,itmaybediscardedbyapplyingaclosetothe descriptor, close(s); DRAFTof8April1993 Leffler/Fabry/Joy 4.2BSDIPCPrimer -7- Basics Ifdataisassociatedwithasocketwhichpromisesreliabledelivery(e.g.astreamsocket)whena closetakesplace,thesystemwillcontinuetoattempttotransferthedata.However,afterafairly longperiodoftime,ifthedataisstillundelivered,itwillbediscarded.Shouldauserhavenouse foranypendingdata,itmayperformashutdownonthesocketpriortoclosingit.Thiscallisof theform: shutdown(s,how); wherehowis0iftheuserisnolongerinterestedinreadingdata,1ifnomoredatawillbesent,or 2ifnodataistobesentorreceived.Applyingshutdowntoasocketcausesanydataqueuedto beimmediatelydiscarded. 0.7.Connectionlesssockets Tothispointwehavebeenconcernedmostlywithsocketswhichfollowaconnectionorientedmodel.However,thereisalsosupportforconnectionlessinteractionstypicalofthedatagramfacilitiesfoundincontemporarypacketswitchednetworks.Adatagramsocketprovidesa symmetricinterfacetodataexchange.Whileprocessesarestilllikelytobeclientandserver, thereisnorequirementforconnectionestablishment.Instead,eachmessageincludesthedestinationaddress. Datagramsocketsarecreatedasbefore,andeachshouldhaveanameboundtoitinorder thattherecipientofamessagemayidentifythesender.Tosenddata,thesendtoprimitiveis used, sendto(s,buf,buflen,flags,&to,tolen); Thes,buf,buflen,andflagsparametersareusedasbefore.Thetoandtolenvaluesareusedto indicatetheintendedrecipientofthemessage.Whenusinganunreliabledatagraminterface,itis unlikelyanyerrorswillbereportedtothesender.Whereinformationispresentlocallytorecognizeamessagewhichmayneverbedelivered(forinstancewhenanetworkisunreachable),the callwillreturn−1andtheglobalvalueerrnowillcontainanerrornumber. Toreceivemessagesonanunconnecteddatagramsocket,therecvfromprimitiveisprovided: recvfrom(s,buf,buflen,flags,&from,&fromlen); Onceagain,thefromlenparameterishandledinavalue-resultfashion,initiallycontainingthesize ofthefrombuffer. Inadditiontothetwocallsmentionedabove,datagramsocketsmayalsousetheconnectcall toassociateasocketwithaspecificaddress.Inthiscase,anydatasentonthesocketwillautomaticallybeaddressedtotheconnectedpeer,andonlydatareceivedfromthatpeerwillbedeliveredtotheuser.Onlyoneconnectedaddressispermittedforeachsocket(i.e.nomulti-casting). Connectrequestsondatagramsocketsreturnimmediately,asthissimplyresultsinthesystem recordingthepeer’saddress(ascomparedtoastreamsocketwhereaconnectrequestinitiates establishmentofanendtoendconnection).Otherofthelessimportantdetailsofdatagram socketsaredescribedinsection5. 0.8.Input/Outputmultiplexing Onelastfacilityoftenusedindevelopingapplicationsistheabilitytomultiplexi/orequests amongmultiplesocketsand/orfiles.Thisisdoneusingtheselectcall: select(nfds,&readfds,&writefds,&execptfds,&timeout); Selecttakesasargumentsthreebitmasks,oneforthesetoffiledescriptorsforwhichthecaller wishestobeabletoreaddataon,oneforthosedescriptorstowhichdataistobewritten,and oneforwhichexceptionalconditionsarepending.Bitmasksarecreatedbyor-ingbitsoftheform ‘‘1<<fd’’.Thatis,adescriptorfdisselectedifa1ispresentinthefd’thbitofthemask.The parameternfdsspecifiestherangeoffiledescriptors(i.e.oneplusthevalueofthelargestdescriptor)specifiedinamask. DRAFTof8April1993 Leffler/Fabry/Joy 4.2BSDIPCPrimer -8- Basics Atimeoutvaluemaybespecifiediftheselectionisnottolastmorethanapredetermined periodoftime.Iftimeoutissetto0,theselectiontakestheformofapoll,returningimmediately. Ifthelastparameterisanullpointer,theselectionwillblockindefinitely*.Selectnormally returnsthenumberoffiledescriptorsselected.Iftheselectcallreturnsduetothetimeoutexpiring,thenavalueof−1isreturnedalongwiththeerrornumberEINTR. Selectprovidesasynchronousmultiplexingscheme.Asynchronousnotificationofoutput completion,inputavailability,andexceptionalconditionsispossiblethroughuseoftheSIGIOand SIGURGsignalsdescribedinsection5. *Tobemorespecific,areturntakesplaceonlywhenadescriptorisselectable,orwhenasignalis receivedbythecaller,interruptingthesystemcall. DRAFTof8April1993 Leffler/Fabry/Joy 4.2BSDIPCPrimer -9-NetworkLibraryRoutines 3.NETWORKLIBRARYROUTINES Thediscussioninsection2indicatedthepossibleneedtolocateandconstructnetwork addresseswhenusingtheinterprocesscommunicationfacilitiesinadistributedenvironment.To aidinthistaskanumberofroutineshavebeenaddedtothestandardCrun-timelibrary.Inthis sectionwewillconsiderthenewroutinesprovidedtomanipulatenetworkaddresses.Whilethe 4.2BSDnetworkingfacilitiessupportonlytheDARPAstandardInternetprotocols,theseroutines havebeendesignedwithflexibilityinmind.Asmorecommunicationprotocolsbecomeavailable, wehopethesameuserinterfacewillbemaintainedinaccessingnetwork-relatedaddressdata bases.Theonlydifferenceshouldbethevaluesreturnedtotheuser.Sincethesevaluesarenormallysuppliedthesystem,usersshouldnotneedtobedirectlyawareofthecommunicationprotocoland/ornamingconventionsinuse. Locatingaserviceonaremotehostrequiresmanylevelsofmappingbeforeclientandserver maycommunicate.Aserviceisassignedanamewhichisintendedforhumanconsumption;e.g. ‘‘theloginserveronhostmonet’’.Thisname,andthenameofthepeerhost,mustthenbetranslatedintonetworkaddresseswhicharenotnecessarilysuitableforhumanconsumption.Finally, theaddressmustthenusedinlocatingaphysicallocationandroutetotheservice.Thespecifics ofthesethreemappingsislikelytovarybetweennetworkarchitectures.Forinstance,itisdesirableforanetworktonotrequirehostsbenamedinsuchawaythattheirphysicallocationis knownbytheclienthost.Instead,underlyingservicesinthenetworkmaydiscovertheactual locationofthehostatthetimeaclienthostwishestocommunicate.Thisabilitytohavehosts namedinalocationindependentmannermayinduceoverheadinconnectionestablishment,asa discoveryprocessmusttakeplace,butallowsahosttobephysicallymobilewithoutrequiringit tonotifyitsclienteleofitscurrentlocation. Standardroutinesareprovidedfor:mappinghostnamestonetworkaddresses,network namestonetworknumbers,protocolnamestoprotocolnumbers,andservicenamestoportnumbersandtheappropriateprotocoltouseincommunicatingwiththeserverprocess.Thefile <netdb.h>mustbeincludedwhenusinganyoftheseroutines. 3.1.Hostnames Ahostnametoaddressmappingisrepresentedbythehostentstructure: structhostent{ char*hname;/*officialnameofhost*/ char**haliases;/*aliaslist*/ inthaddrtype;/*hostaddresstype*/ inthlength;/*lengthofaddress*/ char*haddr;/*address*/ }; Theofficialnameofthehostanditspublicaliasesarereturned,alongwithavariablelength addressandaddresstype.Theroutinegethostbyname(3N)takesahostnameandreturnsahostentstructure,whiletheroutinegethostbyaddr(3N)mapshostaddressesintoahostentstructure. Itispossibleforahosttohavemanyaddresses,allhavingthesamename.Gethostybyname returnsthefirstmatchingentryinthedatabasefile/etc/hosts;ifthisisunsuitable,thelower levelroutinegethostent(3N)maybeused.Forexample,toobtainahostentstructureforahost onaparticularnetworkthefollowingroutinemightbeused(forsimplicity,onlyInternetaddresses areconsidered): DRAFTof8April1993 Leffler/Fabry/Joy 4.2BSDIPCPrimer -10-NetworkLibraryRoutines #include<sys/types.h> #include<sys/socket.h> #include<netinet/in.h> #include<netdb.h> ... structhostent* gethostbynameandnet(name,net) char*name; intnet; { registerstructhostent*hp; registerchar**cp; sethostent(0); while((hp=gethostent())!=NULL){ if(hp->haddrtype!=AFINET) continue; if(strcmp(name,hp->hname)){ for(cp=hp->haliases;cp&&*cp!=NULL;cp++) if(strcmp(name,*cp)==0) gotofound; continue; } found: if(innetof(*(structinaddr*)hp->haddr))==net) break; } endhostent(0); return(hp); } (innetof(3N)isastandardroutinewhichreturnsthenetworkportionofanInternetaddress.) 3.2.Networknames Asforhostnames,routinesformappingnetworknamestonumbers,andback,areprovided. Theseroutinesreturnanetentstructure: /* *Assumptionhereisthatanetworknumber *fitsin32bits--probablyapoorone. */ structnetent{ char*nname;/*officialnameofnet*/ char**naliases;/*aliaslist*/ intnaddrtype;/*netaddresstype*/ intnnet;/*network#*/ }; Theroutinesgetnetbyname(3N),getnetbynumber(3N),andgetnetent(3N)arethenetworkcounterpartstothehostroutinesdescribedabove. 3.3.Protocolnames Forprotocolstheprotoentstructuredefinestheprotocol-namemappingusedwiththerou-tinesgetprotobyname(3N),getprotobynumber(3N),andgetprotoent(3N): DRAFTof8April1993 Leffler/Fabry/Joy 4.2BSDIPCPrimer -11-NetworkLibraryRoutines structprotoent{ char*pname;/*officialprotocolname*/ char**paliases;/*aliaslist*/ intpproto;/*protocol#*/ }; 3.4.Servicenames Informationregardingservicesisabitmorecomplicated.Aserviceisexpectedtoresideat aspecific‘‘port’’andemployaparticularcommunicationprotocol.Thisviewisconsistentwith theInternetdomain,butinconsistentwithothernetworkarchitectures.Further,aservicemay resideonmultipleportsorsupportmultipleprotocols.Ifeitheroftheseoccurs,thehigherlevel libraryroutineswillhavetobebypassedinfavorofhomegrownroutinessimilarinspirittothe ‘‘gethostbynameandnet’’routinedescribedabove.Aservicemappingisdescribedbytheservent structure, structservent{ char*sname;/*officialservicename*/ char**saliases;/*aliaslist*/ intsport;/*port#*/ char*sproto;/*protocoltouse*/ }; Theroutinegetservbyname(3N)mapsservicenamestoaserventstructurebyspecifyingaservice nameand,optionally,aqualifyingprotocol.Thusthecall sp=getservbyname("telnet",(char*)0); returnstheservicespecificationforatelnetserverusinganyprotocol,whilethecall sp=getservbyname("telnet","tcp"); returnsonlythattelnetserverwhichusestheTCPprotocol.Theroutinesgetservbyport(3N)and getservent(3N)arealsoprovided.Thegetservbyportroutinehasaninterfacesimilartothatprovidedbygetservbyname;anoptionalprotocolnamemaybespecifiedtoqualifylookups. 3.5.Miscellaneous Withthesupportroutinesdescribedabove,anapplicationprogramshouldrarelyhaveto dealdirectlywithaddresses.Thisallowsservicestobedevelopedasmuchaspossibleinanetworkindependentfashion.Itisclear,however,thatpurgingallnetworkdependenciesisverydifficult.Solongastheuserisrequiredtosupplynetworkaddresseswhennamingservicesand socketstherewillalwayssomenetworkdependencyinaprogram.Forexample,thenormalcode includedinclientprograms,suchastheremoteloginprogram,isoftheformshowninFigure1. (Thisexamplewillbeconsideredinmoredetailinsection4.) IfwewantedtomaketheremoteloginprogramindependentoftheInternetprotocolsand addressingschemewewouldbeforcedtoaddalayerofroutineswhichmaskedthenetworkdependentaspectsfromthemainstreamlogincode.Forthecurrentfacilitiesavailableinthesystem thisdoesnotappeartobeworthwhile.Perhapswhenthesystemisadaptedtodifferentnetwork architecturestheutilitieswillbereorganizedmorecleanly. Asidefromtheaddress-relateddatabaseroutines,thereareseveralotherroutinesavailable intherun-timelibrarywhichareofinteresttousers.Theseareintendedmostlytosimplify manipulationofnamesandaddresses.Table1summarizestheroutinesformanipulatingvariable lengthbytestringsandhandlingbyteswappingofnetworkaddressesandvalues. Thebyteswappingroutinesareprovidedbecausetheoperatingsystemexpectsaddressesto besuppliedinnetworkorder.OnaVAX,ormachinewithsimilararchitecture,thisisusually reversed.Consequently,programsaresometimesrequiredtobyteswapquantities.Thelibrary routineswhichreturnnetworkaddressesprovidetheminnetworkordersothattheymaysimply DRAFTof8April1993 Leffler/Fabry/Joy 4.2BSDIPCPrimer -12-NetworkLibraryRoutines #include<sys/types.h> #include<sys/socket.h> #include<netinet/in.h> #include<stdio.h> #include<netdb.h> ... main(argc,argv) char*argv[]; { structsockaddrinsin; structservent*sp; structhostent*hp; ints; ... sp=getservbyname("login","tcp"); if(sp==NULL){ fprintf(stderr,"rlogin:tcp/login:unknownservice\n"); exit(1); } hp=gethostbyname(argv[1]); if(hp==NULL){ fprintf(stderr,"rlogin:%s:unknownhost\n",argv[1]); exit(2); } bzero((char*)&sin,sizeof(sin)); bcopy(hp->haddr,(char*)&sin.sinaddr,hp->hlength); sin.sinfamily=hp->haddrtype; sin.sinport=sp->sport; s=socket(AFINET,SOCKSTREAM,0); if(s<0){ perror("rlogin:socket"); exit(3); } ... if(connect(s,(char*)&sin,sizeof(sin))<0){ perror("rlogin:connect"); exit(5); } ... } Figure1.Remoteloginclientcode. CallSynopsis bcmp(s1,s2,n)comparebyte-strings;0ifsame,not0otherwise bcopy(s1,s2,n)copynbytesfroms1tos2 bzero(base,n)zero-fillnbytesstartingatbase htonl(val)convert32-bitquantityfromhosttonetworkbyteorder htons(val)convert16-bitquantityfromhosttonetworkbyteorder ntohl(val)convert32-bitquantityfromnetworktohostbyteorder ntohs(val)convert16-bitquantityfromnetworktohostbyteorder Table1.Crun-timeroutines. becopiedintothestructuresprovidedtothesystem.Thisimpliesusersshouldencounterthe DRAFTof8April1993 Leffler/Fabry/Joy 4.2BSDIPCPrimer -13-NetworkLibraryRoutines byteswappingproblemonlywheninterpretingnetworkaddresses.Forexample,ifanInternet portistobeprintedoutthefollowingcodewouldberequired: printf("portnumber%d\n",ntohs(sp->sport)); OnmachinesotherthantheVAXtheseroutinesaredefinedasnullmacros. DRAFTof8April1993 Leffler/Fabry/Joy 4.2BSDIPCPrimer -14- Client/ServerModel 4.CLIENT/SERVERMODEL Themostcommonlyusedparadigminconstructingdistributedapplicationsisthe client/servermodel.Inthisschemeclientapplicationsrequestservicesfromaserverprocess. Thisimpliesanasymmetryinestablishingcommunicationbetweentheclientandserverwhichhas beenexaminedinsection2.Inthissectionwewilllookmorecloselyattheinteractionsbetween clientandserver,andconsidersomeoftheproblemsindevelopingclientandserverapplications. Clientandserverrequireawellknownsetofconventionsbeforeservicemayberendered (andaccepted).Thissetofconventionscomprisesaprotocolwhichmustbeimplementedatboth endsofaconnection.Dependingonthesituation,theprotocolmaybesymmetricorasymmetric. Inasymmetricprotocol,eithersidemayplaythemasterorslaveroles.Inanasymmetricprotocol,onesideisimmutablyrecognizedasthemaster,withtheothertheslave.Anexampleofa symmetricprotocolistheTELNETprotocolusedintheInternetforremoteterminalemulation. AnexampleofanasymmetricprotocolistheInternetfiletransferprotocol,FTP.Nomatter whetherthespecificprotocolusedinobtainingaserviceissymmetricorasymmetric,whenaccessingaservicethereisa‘‘clientprocess’’anda‘‘serverprocess’’.Wewillfirstconsiderthepropertiesofserverprocesses,thenclientprocesses. Aserverprocessnormallylistensatawellknowaddressforservicerequests.Alternative schemeswhichuseaserviceservermaybeusedtoeliminateaflockofserverprocessesclogging thesystemwhileremainingdormantmostofthetime.TheXeroxCourierprotocolusesthelatter scheme.WhenusingCourier,aCourierclientprocesscontactsaCourierserverattheremote hostandidentifiestheserviceitrequires.TheCourierserverprocessthencreatestheappropriate serverprocessbasedonadatabaseand‘‘splices’’theclientandservertogether,voidingitspartin thetransaction.ThisschemeisattractiveinthattheCourierserverprocessmayprovideasingle contactpointforallservices,aswellascarryingouttheinitialstepsinauthentication.However, whilethisisanattractivepossibilityforstandardizingaccesstoservices,itdoesintroduceacertainamountofoverheadduetotheintermediateprocessinvolved.Implementationswhichprovidethistypeofservicewithinthesystemcanminimizethecostofclientserverrendezvous.The portalnotiondescribedinthe‘‘4.2BSDSystemManual’’embodiesmanyoftheideasfoundin Courier,withtherendezvousmechanismimplementedinternaltothesystem. 4.1.Servers In4.2BSDmostserversareaccessedatwellknownInternetaddressesorUNIXdomain names.Whenaserverisstartedatboottimeitadvertisesitservicesbylisteningatawellknow location.Forexample,theremoteloginserver’smainloopisoftheformshowninFigure2. Thefirststeptakenbytheserverislookupitsservicedefinition: sp=getservbyname("login","tcp"); if(sp==NULL){ fprintf(stderr,"rlogind:tcp/login:unknownservice\n"); exit(1); } ThisdefinitionisusedinlaterportionsofthecodetodefinetheInternetportatwhichitlistens forservicerequests(indicatedbyaconnection). Steptwoistodisassociatetheserverfromthecontrollingterminalofitsinvoker.Thisis importantastheserverwilllikelynotwanttoreceivesignalsdeliveredtotheprocessgroupofthe controllingterminal. Onceaserverhasestablishedapristineenvironment,itcreatesasocketandbeginsacceptingservicerequests.Thebindcallisrequiredtoinsuretheserverlistensatitsexpectedlocation. Themainbodyoftheloopisfairlysimple: DRAFTof8April1993 Leffler/Fabry/Joy 4.2BSDIPCPrimer -15- Client/ServerModel main(argc,argv) intargc; char**argv; { intf; structsockaddrinfrom; structservent*sp; sp=getservbyname("login","tcp"); if(sp==NULL){ fprintf(stderr,"rlogind:tcp/login:unknownservice\n"); exit(1); } ... #ifndefDEBUG <<disassociateserverfromcontrollingterminal>> #endif ... sin.sinport=sp->sport; ... f=socket(AFINET,SOCKSTREAM,0); ... if(bind(f,(caddrt)&sin,sizeof(sin))<0){ ... } ... listen(f,5); for(;;){ intg,len=sizeof(from); g=accept(f,&from,&len); if(g<0){ if(errno!=EINTR) perror("rlogind:accept"); continue; } if(fork()==0){ close(f); doit(g,&from); } close(g); } } Figure2.Remoteloginserver. DRAFTof8April1993 Leffler/Fabry/Joy 4.2BSDIPCPrimer -16- Client/ServerModel for(;;){ intg,len=sizeof(from); g=accept(f,&from,&len); if(g<0){ if(errno!=EINTR) perror("rlogind:accept"); continue; } if(fork()==0){ close(f); doit(g,&from); } close(g); } Anacceptcallblockstheserveruntilaclientrequestsservice.ThiscallcouldreturnafailurestatusifthecallisinterruptedbyasignalsuchasSIGCHLD(tobediscussedinsection5).Therefore,thereturnvaluefromacceptischeckedtoinsureaconnectionhasactuallybeenestablished. Withaconnectioninhand,theserverthenforksachildprocessandinvokesthemainbodyofthe remoteloginprotocolprocessing.Notehowthesocketusedbytheparentforqueueingconnection requestsisclosedinthechild,whilethesocketcreatedasaresultoftheacceptisclosedinthe parent.Theaddressoftheclientisalsohandedthedoitroutinebecauseitrequiresitinauthenticatingclients. 4.2.Clients TheclientsideoftheremoteloginservicewasshownearlierinFigure1.Onecanseethe separate,asymmetricrolesoftheclientandserverclearlyinthecode.Theserverisapassive entity,listeningforclientconnections,whiletheclientprocessisanactiveentity,initiatingaconnectionwheninvoked. Letusconsidermorecloselythestepstakenbytheclientremoteloginprocess.Asinthe serverprocessthefirststepistolocatetheservicedefinitionforaremotelogin: sp=getservbyname("login","tcp"); if(sp==NULL){ fprintf(stderr,"rlogin:tcp/login:unknownservice\n"); exit(1); } Nextthedestinationhostislookedupwithagethostbynamecall: hp=gethostbyname(argv[1]); if(hp==NULL){ fprintf(stderr,"rlogin:%s:unknownhost\n",argv[1]); exit(2); } Withthisaccomplished,allthatisrequiredistoestablishaconnectiontotheserveratthe requestedhostandstartuptheremoteloginprotocol.Theaddressbufferiscleared,thenfilledin withtheInternetaddressoftheforeignhostandtheportnumberatwhichtheloginprocess resides: bzero((char*)&sin,sizeof(sin)); bcopy(hp->haddr,(char*)sin.sinaddr,hp->hlength); sin.sinfamily=hp->haddrtype; sin.sinport=sp->sport; DRAFTof8April1993 Leffler/Fabry/Joy 4.2BSDIPCPrimer -17- Client/ServerModel Asocketiscreated,andaconnectioninitiated. s=socket(hp->haddrtype,SOCKSTREAM,0); if(s<0){ perror("rlogin:socket"); exit(3); } ... if(connect(s,(char*)&sin,sizeof(sin))<0){ perror("rlogin:connect"); exit(4); } Thedetailsoftheremoteloginprotocolwillnotbeconsideredhere. 4.3.Connectionlessservers Whileconnection-basedservicesarethenorm,someservicesarebasedontheuseofdata-gramsockets.One,inparticular,isthe‘‘rwho’’servicewhichprovidesuserswithstatusinforma-tionforhostsconnectedtoalocalareanetwork.Thisservice,whilepredicatedontheabilityto broadcastinformationtoallhostsconnectedtoaparticularnetwork,isofinterestasanexample usageofdatagramsockets. Auseronanymachinerunningtherwhoservermayfindoutthecurrentstatusofa machinewiththeruptime(1)program.TheoutputgeneratedisillustratedinFigure3. arpaup9:45,5users,load1.15,1.39,1.31 cadup2+12:04,8users,load4.67,5.13,4.59 calderup10:10,0users,load0.27,0.15,0.14 daliup2+06:28,9users,load1.04,1.20,1.65 degasup25+09:48,0users,load1.49,1.43,1.41 earup5+00:05,0users,load1.51,1.54,1.56 erniedown0:24 esvaxdown17:04 ingresdown0:26 kimup3+09:16,8users,load2.03,2.46,3.11 matisseup3+06:18,0users,load0.03,0.03,0.05 medeaup3+09:39,2users,load0.35,0.37,0.50 merlindown19+15:37 miroup1+07:20,7users,load4.59,3.28,2.12 monetup1+00:43,2users,load0.22,0.09,0.07 ozdown16:09 statvaxup2+15:57,3users,load1.52,1.81,1.86 ucbvaxup9:34,2users,load6.08,5.16,3.28 Figure3.ruptimeoutput. Statusinformationforeachhostisperiodicallybroadcastbyrwhoserverprocessesoneach machine.Thesameserverprocessalsoreceivesthestatusinformationandusesittoupdatea database.Thisdatabaseistheninterpretedtogeneratethestatusinformationforeachhost. Serversoperateautonomously,coupledonlybythelocalnetworkanditsbroadcastcapabilities. Therwhoserver,inasimplifiedform,ispicturedinFigure4.Therearetwoseparatetasks performedbytheserver.Thefirsttaskistoactasareceiverofstatusinformationbroadcastby otherhostsonthenetwork.Thisjobiscarriedoutinthemainloopoftheprogram.Packets receivedattherwhoportareinterrogatedtoinsurethey’vebeensentbyanotherrwhoserverprocess,thenaretimestampedwiththeirarrivaltimeandusedtoupdateafileindicatingthestatus DRAFTof8April1993 Leffler/Fabry/Joy 4.2BSDIPCPrimer -18- Client/ServerModel ofthehost.Whenahosthasnotbeenheardfromforanextendedperiodoftime,thedatabase interpretationroutinesassumethehostisdownandindicatesuchonthestatusreports.This algorithmispronetoerrorasaservermaybedownwhileahostisactuallyup,butservesour currentneeds. main() { ... sp=getservbyname("who","udp"); net=getnetbyname("localnet"); sin.sinaddr=inetmakeaddr(INADDRANY,net); sin.sinport=sp->sport; ... s=socket(AFINET,SOCKDGRAM,0); ... bind(s,&sin,sizeof(sin)); ... sigset(SIGALRM,onalrm); onalrm(); for(;;){ structwhodwd; intcc,whod,len=sizeof(from); cc=recvfrom(s,(char*)&wd,sizeof(structwhod),0,&from,&len); if(cc<=0){ if(cc<0&&errno!=EINTR) perror("rwhod:recv"); continue; } if(from.sinport!=sp->sport){ fprintf(stderr,"rwhod:%d:badfromport\n", ntohs(from.sinport)); continue; } ... if(!verify(wd.wdhostname)){ fprintf(stderr,"rwhod:malformedhostnamefrom%x\n", ntohl(from.sinaddr.saddr)); continue; } (void)sprintf(path,"%s/whod.%s",RWHODIR,wd.wdhostname); whod=open(path,FWRONLY|FCREATE|FTRUNCATE,0666); ... (void)time(&wd.wdrecvtime); (void)write(whod,(char*)&wd,cc); (void)close(whod); } } Figure4.rwhoserver. Thesecondtaskperformedbytheserveristosupplyinformationregardingthestatusofits host.Thisinvolvesperiodicallyacquiringsystemstatusinformation,packagingitupinamessage andbroadcastingitonthelocalnetworkforotherrwhoserverstohear.Thesupplyfunctionis triggeredbyatimerandrunsoffasignal.Locatingthesystemstatusinformationissomewhat involved,butuninteresting.Decidingwheretotransmittheresultantpacketdoes,however, DRAFTof8April1993 Leffler/Fabry/Joy 4.2BSDIPCPrimer -19- Client/ServerModel indicatessomeproblemswiththecurrentprotocol. Statusinformationisbroadcastonthelocalnetwork.Fornetworkswhichdonotsupport thenotionofbroadcastanotherschememustbeusedtosimulateorreplacebroadcasting.One possibilityistoenumeratetheknownneighbors(basedonthestatusreceived).This,unfortunately,requiressomebootstrappinginformation,asaserverstarteduponaquietnetworkwill havenoknownneighborsandthusneverreceive,orsend,anystatusinformation.Thisisthe identicalproblemfacedbytheroutingtablemanagementprocessinpropagatingroutingstatus information.Thestandardsolution,unsatisfactoryasitmaybe,istoinformoneormoreservers ofknownneighborsandrequestthattheyalwayscommunicatewiththeseneighbors.Ifeach serverhasatleastoneneighborsuppliedit,statusinformationmaythenpropagatethrougha neighbortohostswhicharenot(possibly)directlyneighbors.Iftheserverisabletosupportnetworkswhichprovideabroadcastcapability,aswellasthosewhichdonot,thennetworkswithan arbitrarytopologymaysharestatusinformation*. Thesecondproblemwiththecurrentschemeisthattherwhoprocessservicesonlyasingle localnetwork,andthisnetworkisfoundbyreadingafile.Itisimportantthatsoftwareoperating inadistributedenvironmentnothaveanysite-dependentinformationcompiledintoit.This wouldrequireaseparatecopyoftheserverateachhostandmakemaintenanceasevereheadache. 4.2BSDattemptstoisolatehost-specificinformationfromapplicationsbyprovidingsystemcalls whichreturnthenecessaryinformation†.Unfortunately,nostraightforwardmechanismcurrently existsforfindingthecollectionofnetworkstowhichahostisdirectlyconnected.Thustherwho serverperformsalookupinafiletofinditslocalnetwork.Abetter,thoughstillunsatisfactory, schemeusedbytheroutingprocessistointerrogatethesystemdatastructurestolocatethose directlyconnectednetworks.Amechanismtoacquirethisinformationfromthesystemwouldbe ausefuladdition. *Onemust,however,beconcernedabout‘‘loops’’.Thatis,ifahostisconnectedtomultiplenetworks,itwillreceivestatusinformationfromitself.Thiscanleadtoanendless,wasteful,exchangeof information. †Anexampleofsuchasystemcallisthegethostname(2)callwhichreturnsthehost’s‘‘official’’name. DRAFTof8April1993 Leffler/Fabry/Joy 4.2BSDIPCPrimer -20- AdvancedTopics 5.ADVANCEDTOPICS Anumberoffacilitieshaveyettobediscussed.Formostusersoftheipcthemechanisms alreadydescribedwillsufficeinconstructingdistributedapplications.However,otherswillfind needtoutilizesomeofthefeatureswhichweconsiderinthissection. 5.1.Outofbanddata Thestreamsocketabstractionincludesthenotionof‘‘outofband’’data.Outofbanddata isalogicallyindependenttransmissionchannelassociatedwitheachpairofconnectedstream sockets.Outofbanddataisdeliveredtotheuserindependentlyofnormaldataalongwiththe SIGURGsignal.Inadditiontotheinformationpassed,alogicalmarkisplacedinthedata streamtoindicatethepointatwhichtheoutofbanddatawassent.Theremoteloginand remoteshellapplicationsusethisfacilitytopropagatesignalsfrombetweenclientandserverprocesses.Whenasignalisexpectedtoflushanypendingoutputfromtheremoteprocess(es),all datauptothemarkinthedatastreamisdiscarded. Thestreamabstractiondefinesthattheoutofbanddatafacilitiesmustsupportthereliable deliveryofatleastoneoutofbandmessageatatime.Thismessagemaycontainatleastone byteofdata,andatleastonemessagemaybependingdeliverytotheuseratanyonetime.For communicationsprotocolswhichsupportonlyin-bandsignaling(i.e.theurgentdataisdelivered insequencewiththenormaldata)thesystemextractsthedatafromthenormaldatastreamand storesitseparately.Thisallowsuserstochoosebetweenreceivingtheurgentdatainorderand receivingitoutofsequencewithouthavingtobufferalltheinterveningdata. TosendanoutofbandmessagetheSOFOOBflagissuppliedtoasendorsendtocalls, whiletoreceiveoutofbanddataSOFOOBshouldbeindicatedwhenperformingarecvfromor recvcall.Tofindoutifthereadpointeriscurrentlypointingatthemarkinthedatastream,the SIOCATMARKioctlisprovided: ioctl(s,SIOCATMARK,&yes); Ifyesisa1onreturn,thenextreadwillreturndataafterthemark.Otherwise(assumingoutof banddatahasarrived),thenextreadwillprovidedatasentbytheclientpriortotransmissionof theoutofbandsignal.Theroutineusedintheremoteloginprocesstoflushoutputonreceiptof aninterruptorquitsignalisshowninFigure5. 5.2.Signalsandprocessgroups DuetotheexistenceoftheSIGURGandSIGIOsignalseachsockethasanassociatedprocessgroup(justasisdoneforterminals).Thisprocessgroupisinitializedtotheprocessgroupof itscreator,butmayberedefinedatalatertimewiththeSIOCSPGRPioctl: ioctl(s,SIOCSPGRP,&pgrp); Asimilarioctl,SIOCGPGRP,isavailablefordeterminingthecurrentprocessgroupofasocket. 5.3.Pseudoterminals Manyprogramswillnotfunctionproperlywithoutaterminalforstandardinputandoutput.Sinceasocketisnotaterminal,itisoftennecessarytohaveaprocesscommunicatingover thenetworkdosothroughapseudoterminal.Apseudoterminalisactuallyapairofdevices, masterandslave,whichallowaprocesstoserveasanactiveagentincommunicationbetween processesandusers.Datawrittenontheslavesideofapseudoterminalissuppliedasinputtoa processreadingfromthemasterside.Datawrittenonthemastersideisgiventheslaveasinput. Inthisway,theprocessmanipulatingthemastersideofthepseudoterminalhascontroloverthe informationreadandwrittenontheslaveside.Theremoteloginserverusespseudoterminalsfor remoteloginsessions.Auserloggingintoamachineacrossthenetworkisprovidedashellwith aslavepseudoterminalasstandardinput,output,anderror.Theserverprocessthenhandlesthe DRAFTof8April1993 Leffler/Fabry/Joy 4.2BSDIPCPrimer -21- AdvancedTopics oob() { intout=1+1; charwaste[BUFSIZ],mark; signal(SIGURG,oob); /*flushlocalterminalinputandoutput*/ ioctl(1,TIOCFLUSH,(char*)&out); for(;;){ if(ioctl(rem,SIOCATMARK,&mark)<0){ perror("ioctl"); break; } if(mark) break; (void)read(rem,waste,sizeof(waste)); } recv(rem,&mark,1,SOFOOB); ... } Figure5.Flushingterminali/oonreceiptofoutofbanddata. communicationbetweentheprogramsinvokedbytheremoteshellandtheuser’slocalclientprocess.Whenausersendsaninterruptorquitsignaltoaprocessexecutingonaremotemachine, theclientloginprogramtrapsthesignal,sendsanoutofbandmessagetotheserverprocesswho thenusesthesignalnumber,sentasthedatavalueintheoutofbandmessage,toperforma killpg(2)ontheappropriateprocessgroup. 5.4.Internetaddressbinding BindingaddressestosocketsintheInternetdomaincanbefairlycomplex.Communicating processesareboundbyanassociation.Anassociationiscomposedoflocalandforeignaddresses, andlocalandforeignports.Portnumbersareallocatedoutofseparatespaces,oneforeachInternetprotocol.Associationsarealwaysunique.Thatis,theremayneverbeduplicate<protocol, localaddress,localport,foreignaddress,foreignport>tuples. Thebindsystemcallallowsaprocesstospecifyhalfofanassociation,<localaddress,local port>,whiletheconnectandacceptprimitivesareusedtocompleteasocket’sassociation.Since theassociationiscreatedintwostepstheassociationuniquenessrequirementindicatedabove couldbeviolatedunlesscareistaken.Further,itisunrealistictoexpectuserprogramstoalways knowpropervaluestouseforthelocaladdressandlocalportsinceahostmayresideonmultiple networksandthesetofallocatedportnumbersisnotdirectlyaccessibletoauser. Tosimplifylocaladdressbindingthenotionofa‘‘wildcard’’addresshasbeenprovided. WhenanaddressisspecifiedasINADDRANY(amanifestconstantdefinedin<netinet/in.h>), thesysteminterpretstheaddressas‘‘anyvalidaddress’’.Forexample,tobindaspecificport numbertoasocket,butleavethelocaladdressunspecified,thefollowingcodemightbeused: DRAFTof8April1993 Leffler/Fabry/Joy 4.2BSDIPCPrimer -22- AdvancedTopics #include<sys/types.h> #include<netinet/in.h> ... structsockaddrinsin; ... s=socket(AFINET,SOCKSTREAM,0); sin.sinfamily=AFINET; sin.sinaddr.saddr=INADDRANY; sin.sinport=MYPORT; bind(s,(char*)&sin,sizeof(sin)); Socketswithwildcardedlocaladdressesmayreceivemessagesdirectedtothespecifiedportnumber,andaddressedtoanyofthepossibleaddressesassignedahost.Forexample,ifahostisona networks46and10andasocketisboundasabove,thenanacceptcallisperformed,theprocess willbeabletoacceptconnectionrequestswhicharriveeitherfromnetwork46ornetwork10. Inasimilarfashion,alocalportmaybeleftunspecified(specifiedaszero),inwhichcasethe systemwillselectanappropriateportnumberforit.Forexample: sin.sinaddr.saddr=MYADDRESS; sin.sinport=0; bind(s,(char*)&sin,sizeof(sin)); Thesystemselectstheportnumberbasedontwocriteria.Thefirstisthatportsnumbered0 through1023arereservedforprivilegedusers(i.e.thesuperuser).Thesecondisthattheport numberisnotcurrentlyboundtosomeothersocket.Inordertofindafreeportnumberinthe privilegedrangethefollowingcodeisusedbytheremoteshellserver: structsockaddrinsin; ... lport=IPPORTRESERVED−1; sin.sinaddr.saddr=INADDRANY; ... for(;;){ sin.sinport=htons((ushort)lport); if(bind(s,(caddrt)&sin,sizeof(sin))>=0) break; if(errno!=EADDRINUSE&&errno!=EADDRNOTAVAIL){ perror("socket"); break; } lport--; if(lport==IPPORTRESERVED/2){ fprintf(stderr,"socket:Allportsinuse\n"); break; } } Therestrictiononallocatingportswasdonetoallowprocessesexecutingina‘‘secure’’environmenttoperformauthenticationbasedontheoriginatingaddressandportnumber. Incertaincasesthealgorithmusedbythesysteminselectingportnumbersisunsuitablefor anapplication.Thisisduetoassociationsbeingcreatedinatwostepprocess.Forexample,the Internetfiletransferprotocol,FTP,specifiesthatdataconnectionsmustalwaysoriginatefromthe samelocalport.However,duplicateassociationsareavoidedbyconnectingtodifferentforeign ports.Inthissituationthesystemwoulddisallowbindingthesamelocaladdressandport numbertoasocketifapreviousdataconnection’ssocketwerearound.Tooverridethedefault portselectionalgorithmthenanoptioncallmustbeperformedpriortoaddressbinding: DRAFTof8April1993 Leffler/Fabry/Joy 4.2BSDIPCPrimer -23- AdvancedTopics setsockopt(s,SOLSOCKET,SOREUSEADDR,(char*)0,0); bind(s,(char*)&sin,sizeof(sin)); Withtheabovecall,localaddressesmaybeboundwhicharealreadyinuse.Thisdoesnotviolatetheuniquenessrequirementasthesystemstillchecksatconnecttimetobesureanyother socketswiththesamelocaladdressandportdonothavethesameforeignaddressandport(ifan associationalreadyexists,theerrorEADDRINUSEisreturned). Localaddressbindingbythesystemiscurrentlydonesomewhathaphazardlywhenahostis onmultiplenetworks.Logically,onewouldexpectthesystemtobindthelocaladdressassociated withthenetworkthroughwhichapeerwascommunicating.Forinstance,ifthelocalhostisconnectedtonetworks46and10andtheforeignhostisonnetwork32,andtrafficfromnetwork32 werearrivingvianetwork10,thelocaladdresstobeboundwouldbethehost’saddressonnetwork10,notnetwork46.Thisunfortunately,isnotalwaysthecase.Forreasonstoocomplicated todiscusshere,thelocaladdressboundmaybeappeartobechosenatrandom.Thispropertyof localaddressbindingwillnormallybeinvisibletousersunlesstheforeignhostdoesnotunderstandhowtoreachtheaddressselected*. 5.5.Broadcastinganddatagramsockets Byusingadatagramsocketitispossibletosendbroadcastpacketsonmanynetworkssupportedbythesystem(thenetworkitselfmustsupportthenotionofbroadcasting;thesystemprovidesnobroadcastsimulationinsoftware).Broadcastmessagescanplaceahighloadonanetworksincetheyforceeveryhostonthenetworktoservicethem.Consequently,theabilitytosend broadcastpacketshasbeenlimitedtothesuperuser. Tosendabroadcastmessage,anInternetdatagramsocketshouldbecreated: s=socket(AFINET,SOCKDGRAM,0); andatleastaportnumbershouldbeboundtothesocket: sin.sinfamily=AFINET; sin.sinaddr.saddr=INADDRANY; sin.sinport=MYPORT; bind(s,(char*)&sin,sizeof(sin)); Thenthemessageshouldbeaddressedas: dst.sinfamily=AFINET; dst.sinaddr.saddr=INADDRANY; dst.sinport=DESTPORT; and,finally,asendtocallmaybeused: sendto(s,buf,buflen,0,&dst,sizeof(dst)); Receivedbroadcastmessagescontainthesendersaddressandport(datagramsocketsare anchoredbeforeamessageisallowedtogoout). 5.6.Signals Twonewsignalshavebeenaddedtothesystemwhichmaybeusedinconjunctionwiththe interprocesscommunicationfacilities.TheSIGURGsignalisassociatedwiththeexistenceofan ‘‘urgentcondition’’.TheSIGIOsignalisusedwith‘‘interruptdriveni/o’’(notpresentlyimplemented).SIGURGiscurrentlysuppliedaprocesswhenoutofbanddataispresentatasocket. Ifmultiplesocketshaveoutofbanddataawaitingdelivery,aselectcallmaybeusedtodetermine thosesocketswithsuchdata. *Forexample,ifnetwork46wereunknowntothehostonnetwork32,andthelocaladdresswere boundtothatlocatedonnetwork46,theneventhougharoutebetweenthetwohostsexistedthrough network10,aconnectionwouldfail. DRAFTof8April1993 Leffler/Fabry/Joy 4.2BSDIPCPrimer -24- AdvancedTopics AnoldsignalwhichisusefulwhenconstructingserverprocessesisSIGCHLD.Thissignalis deliveredtoaprocesswhenanychildrenprocesseshavechangedstate.Normallyserversusethe signalto‘‘reap’’childprocessesafterexiting.Forexample,theremoteloginserverloopshownin Figure2maybeaugmentedasfollows: intreaper(); ... sigset(SIGCHLD,reaper); listen(f,10); for(;;){ intg,len=sizeof(from); g=accept(f,&from,&len,0); if(g<0){ if(errno!=EINTR) perror("rlogind:accept"); continue; } ... } ... #include<wait.h> reaper() { unionwaitstatus; while(wait3(&status,WNOHANG,0)>0) ; } Iftheparentserverprocessfailstoreapitschildren,alargenumberof‘‘zombie’’processes maybecreated. DRAFTof8April1993 Leffler/Fabry/Joy