BSD进程间通信高级编程指南,主要讲socket编程pdf.pdf
An Advanced 4.4BSD Interprocess Communication TutorialSamuel J.LefflerRobert S.FabryWilliam N.JoyPhil LapsleyComputer Systems Research GroupDepartment of Electrical Engineering and Computer ScienceUniversity of California,BerkeleyBerkeley,California 94720Steve MillerChris TorekHeterogeneous Systems LaboratoryDepartment of Computer ScienceUniversity of Maryland,College ParkCollege Park,Maryland 20742ABSTRACTThis document provides an introduction to the interprocess communication facili-ties included in the 4.4BSD release of the UNIX*system.It discusses the overall model for interprocess communication and introduces theinterprocess communication primitives which have been added to the system.The major-ity of the document considers the use of these primitives in dev eloping applications.Thereader is expected to be familiar with the C programming language as all examples arewritten in C.*UNIXis a trademark of UNIX System Laboratories,Inc.in the US and some other countries.PSD:21-2 Advanced 4.4BSD IPC Tutorial1.INTRODUCTIONOne of the most important additions to UNIX in 4.2BSD was interprocess communication.These facilitieswere the result of more than two years of discussion and research.The facilities provided in 4.2BSD incor-porated many of the ideas from current research,while trying to maintain the UNIX philosophy of simplic-ity and conciseness.The 4.3BSD release of Berkeley UNIX improved upon some of the IPC facilitieswhile providing an upward-compatible interface.4.4BSD adds support for ISO protocols and IP multicast-ing.The BSD interprocess communication facilities have become a defacto standard for UNIX.UNIX has previously been very weak in the area of interprocess communication.Prior to the 4BSDfacilities,the only standard mechanism which allowed two processes to communicate were pipes(the mpxfiles which were part of Version 7 were experimental).Unfortunately,pipes are very restrictive in that thetwo communicating processes must be related through a common ancestor.Further,the semantics of pipesmakes them almost impossible to maintain in a distributed environment.Earlier attempts at extending the IPC facilities of UNIX have met with mixed reaction.The majorityof the problems have been related to the fact that these facilities have been tied to the UNIX file system,either through naming or implementation.Consequently,the IPC facilities provided in 4.2BSD weredesigned as a totally independent subsystem.The BSD IPC allows processes to rendezvous in many ways.Processes may rendezvous through a UNIX file system-like name space(a space where all names are pathnames)as well as through a network name space.In fact,new name spaces may be added at a future timewith only minor changes visible to users.Further,the communication facilities have been extended toinclude more than the simple byte stream provided by a pipe.These extensions have resulted in a com-pletely new part of the system which users will need time to familiarize themselves with.It is likely that asmore use is made of these facilities they will be refined;only time will tell.This document provides a high-level description of the IPC facilities in 4.4BSD and their use.It isdesigned to complement the manual pages for the IPC primitives by examples of their use.The remainderof this document is organized in four sections.Section 2 introduces the IPC-related system calls and thebasic model of communication.Section 3 describes some of the supporting library routines users may finduseful in constructing distributed applications.Section 4 is concerned with the client/server model used indeveloping applications and includes examples of the two major types of servers.Section 5 delves intoadvanced topics which sophisticated users are likely to encounter when using the IPC facilities.Advanced 4.4BSD IPC Tutorial PSD:21-32.BASICSThe basic building block for communication is the socket.A socket is an endpoint of communicationto which a name may be bound.Each socket in use has a type and one or more associated processes.Sock-ets exist within communication domains.A communication domain is an abstraction introduced to bundlecommon properties of processes communicating through sockets.One such property is the scheme used toname sockets.For example,in the UNIX communication domain sockets are named with UNIX pathnames;e.g.a socket may be named/dev/foo.Sockets normally exchange data only with sockets in thesame domain(it may be possible to cross domain boundaries,but only if some translation process is per-formed).The 4.4BSD IPC facilities support four separate communication domains:the UNIX domain,foron-system communication;the Internet domain,which is used by processes which communicate using theInternet standard communication protocols;the NS domain,which is used by processes which communi-cate using the Xerox standard communication protocols*;and the ISO OSI protocols,which are not docu-mented in this tutorial.The underlying communication facilities provided by these domains have a signifi-cant influence on the internal system implementation as well as the interface to socket facilities available toa user.An example of the latter is that a socket operating in the UNIX domain sees a subset of the errorconditions which are possible when operating in the Internet(or NS)domain.2.1.Socket typesSockets are typed according to the communication properties visible to a user.Processes are pre-sumed to communicate only between sockets of the same type,although there is nothing that prevents com-munication between sockets of different types should the underlying communication protocols support this.Four types of sockets currently are available to a user.A stream socket provides for the bidirectional,reliable,sequenced,and unduplicated flow of data without record boundaries.Aside from the bidirectional-ity of data flow,a pair of connected stream sockets provides an interface nearly identical to that of pipes.A datagram socket supports bidirectional flow of data which is not promised to be sequenced,reli-able,or unduplicated.That is,a process receiving messages on a datagram socket may find messagesduplicated,and,possibly,in an order different from the order in which it was sent.An important character-istic of a datagram socket is that record boundaries in data are preserved.Datagram sockets closely modelthe facilities found in many contemporary packet switched networks such as the Ethernet.A raw socket provides users access to the underlying communication protocols which support socketabstractions.These sockets are normally datagram oriented,though their exact characteristics are depen-dent on the interface provided by the protocol.Raw sockets are not intended for the general user;they hav ebeen provided mainly for those interested in developing new communication protocols,or for gainingaccess to some of the more esoteric facilities of an existing protocol.The use of raw sockets is consideredin section 5.A sequenced packet socket is similar to a stream socket,with the exception that record boundaries arepreserved.This interface is provided only as part of the NS socket abstraction,and is very important inmost serious NS applications.Sequenced-packet sockets allow the user to manipulate the SPP or IDP head-ers on a packet or a group of packets either by writing a prototype header along with whatever data is to besent,or by specifying a default header to be used with all outgoing data,and allows the user to receive theheaders on incoming packets.The use of these options is considered in section 5.Another potential socket type which has interesting properties is the reliably delivered messagesocket.The reliably delivered message socket has similar properties to a datagram socket,but with reliabledelivery.There is currently no support for this type of socket,but a reliably delivered message protocolsimilar to Xeroxs Packet Exchange Protocol(PEX)may be simulated at the user level.More information*See Internet Transport Protocols,Xerox System Integration Standard(XSIS)028112 for more information.This docu-ment is almost a necessity for one trying to write NS applications.In the UNIX domain,in fact,the semantics are identical and,as one might expect,pipes have been implemented internal-ly as simply a pair of connected stream sockets.PSD:21-4 Advanced 4.4BSD IPC Tutorialon this topic can be found in section 5.2.2.Socket creationTo create a socket the socket system call is used:s=socket(domain,type,protocol);This call requests that the system create a socket in the specified domain and of the specified type.A par-ticular protocol may also be requested.If the protocol is left unspecified(a value of 0),the system willselect an appropriate protocol from those protocols which comprise the communication domain and whichmay be used to support the requested socket type.The user is returned a descriptor(a small integer num-ber)which may be used in later system calls which operate on sockets.The domain is specified as one ofthe manifest constants defined in the file.For the UNIX domain the constant is AF_UNIX*;for the Internet domain AF_INET;and for the NS domain,AF_NS.The socket types are also defined inthis file and one of SOCK_STREAM,SOCK_DGRAM,SOCK_RAW,or SOCK_SEQPACKET must bespecified.To create a stream socket in the Internet domain the following call might be used:s=socket(AF_INET,SOCK_STREAM,0);This call would result in a stream socket being created with the TCP protocol providing the underlyingcommunication support.To create a datagram socket for on-machine use the call might be:s=socket(AF_UNIX,SOCK_DGRAM,0);The default protocol(used when the protocol argument to the socket call is 0)should be correct formost every situation.However,it is possible to specify a protocol other than the default;this will be cov-ered in section 5.There are several reasons a socket call may fail.Aside from the rare occurrence of lack of memory(ENOBUFS),a socket request may fail due to a request for an unknown protocol(EPROT ONOSUPPORT),or a request for a type of socket for which there is no supporting protocol(EPROT OTYPE).2.3.Binding local namesA socket is created without a name.Until a name is bound to a socket,processes have no way to ref-erence it and,consequently,no messages may be received on it.Communicating processes are bound by anassociation.In the Internet and NS domains,an association is composed of local and foreign addresses,and local and foreign ports,while in the UNIX domain,an association is composed of local and foreignpath names(the phrase foreign pathname means a pathname created by a foreign process,not a path-name on a foreign system).In most domains,associations must be unique.In the Internet domain theremay never be duplicate tuples.UNIXdomain sockets need not always be bound to a name,but when bound there may never be duplicate tuples.The pathnames may not refer to files already existing onthe system in 4.3;the situation may change in future releases.The bind system call allows a process to specify half of an association,(or),while the connect and accept primitives are used to complete a sockets association.In the Internet domain,binding names to sockets can be fairly complex.Fortunately,it is usually notnecessary to specifically bind an address and port number to a socket,because the connect and send callswill automatically bind an appropriate address if they are used with an unbound socket.The process ofbinding names to NS sockets is similar in most ways to that of binding names to Internet sockets.The bind system call is used as follows:bind(s,name,namelen);The bound name is a variable length byte string which is interpreted by the supporting protocol(s).Itsinterpretation may vary from communication domain to communication domain(this is one of the*The manifest constants are named AF_whatever as they indicate the address format to use in interpreting names.Advanced 4.4BSD IPC Tutorial PSD:21-5properties which comprise the domain).As mentioned,in the Internet domain names contain an Internetaddress and port number.NS domain names contain an NS address and port number.In the UNIX domain,names contain a path name and a family,which is always AF_UNIX.If one wanted to bind the name/tmp/foo to a UNIX domain socket,the following code would be used*:#include.struct sockaddr_un addr;.strcpy(addr.sun_path,/tmp/foo);addr.sun_family=AF_UNIX;bind(s,(struct sockaddr*)&addr,strlen(addr.sun_path)+sizeof(addr.sun_len)+sizeof(addr.sun_family);Note that in determining the size of a UNIX domain address null bytes are not counted,which is why strlenis used.In the current implementation of UNIX domain IPC,the file name referred to in addr.sun_path iscreated as a socket in the system file space.The caller must,therefore,have write permission in the direc-tory where addr.sun_path is to reside,and this file should be deleted by the caller when it is no longerneeded.Future versions of 4BSD may not create this file.In binding an Internet address things become more complicated.The actual call is similar,#include#include.struct sockaddr_in sin;.bind(s,(struct sockaddr*)&sin,sizeof(sin);but the selection of what to place in the address sin requires some discussion.We will come back to theproblem of formulating Internet addresses in section 3 when the library routines used in name resolutionare discussed.Binding an NS address to a socket is even more difficult,especially since the Internet library routinesdo not work with NS hostnames.The actual call is again similar:#include#include.struct sockaddr_ns sns;.bind(s,(struct sockaddr*)&sns,sizeof(sns);Again,discussion of what to place in a struct sockaddr_ns will be deferred to section 3.2.4.Connection establishmentConnection establishment is usually asymmetric,with one process a client and the other aserver.The server,when willing to offer its advertised services,binds a socket to a well-known addressassociated with the service and then passively listens on its socket.It is then possible for an unrelatedprocess to rendezvous with the server.The client requests services from the server by initiating a connec-tion to the servers socket.On the client side the connect call is used to initiate a connection.Using theUNIX domain,this might appear as,*Note that,although the tendency here is to call the addr structure sun,doing so would cause problems if the codewere ever ported to a Sun workstation.PSD:21-6 Advanced 4.4BSD IPC Tutorialstruct sockaddr_un server;.connect(s,(struct sockaddr*)&server,strlen(server.sun_path)+sizeof(server.sun_family);while in the Internet domain,struct sockaddr_in server;.connect(s,(struct sockaddr*)&server,sizeof(server);and in the NS domain,struct sockaddr_ns server;.connect(s,(struct sockaddr*)&server,sizeof(server);where server in the example above would contain either the UNIX pathname,Internet address and portnumber,or NS address and port number of the server to which the client process wishes to speak.If theclient processs socket is unbou
