Networking Implementation Notes4.4BSD EditionSamuel J.Leffler,William N. Joy,Robert S. Fabry,and Michael J.KarelsComputer Systems Research GroupComputer Science DivisionDepartment of Electrical Engineering and Computer ScienceUniversity of California, BerkeleyBerkeley, CA94720ABSTRACTThis report describes the internal structure of the networking facilities developedfor the 4.4BSD version of the UNIX* operating system for the VAX†. These facilitiesare based on several central abstractions which structure the external (user) viewofnet-work communication as well as the internal (system) implementation.The report documents the internal structure of the networking system. The‘‘BerkeleySoftware Architecture Manual, 4.4BSD Edition’’(PSD:5) provides a descrip-tion of the user interface to the networking facilities.Revised June 10, 1993*UNIX is a trademark of Bell Laboratories.†DEC, VAX, DECnet, and UNIBUS are trademarks of Digital Equipment Corporation.SMM:18-2 Networking Implementation NotesTABLE OF CONTENTS1. Introduction2. Overview3. Goals4. Internal address representation5. Memory management6. Internal layering6.1. Socket layer6.1.1. Socket state6.1.2. Socket data queues6.1.3. Socket connection queuing6.2. Protocol layer(s)6.3. Network-interface layer6.3.1. UNIBUS interfaces7. Socket/protocol interface8. Protocol/protocol interface8.1. pr_output8.2. pr_input8.3. pr_ctlinput8.4. pr_ctloutput9. Protocol/network-interface interface9.1. Packet transmission9.2. Packet reception10. Gateways and routing issues10.1. Routing tables10.2. Routing table interface10.3. User levelrouting policies11. Raw sockets11.1. Control blocks11.2. Input processing11.3. Output processing12. Buffering and congestion control12.1. Memory management12.2. Protocol buffering policies12.3. Queue limiting12.4. Packet forwarding13. Out of band data14. Trailer protocolsAcknowledgementsReferencesNetworking Implementation Notes SMM:18-31. IntroductionThis report describes the internal structure of facilities added to the 4.2BSD version of the UNIXoperating system for the VAX, as modified in the 4.4BSD release. The system facilities provide a uniformuser interface to networking within UNIX. In addition, the implementation introduces a structure for net-work communications which may be used by system implementors in adding newnetworking facilities.The internal structure is not visible to the user,rather it is intended to aid implementors of communicationprotocols and network services by providing a framework which promotes code sharing and minimizesimplementation effort.The reader is expected to be familiar with the C programming language and system interface, asdescribed in the BerkeleySoftwareArc h itectureManual, 4.4BSD Edition [Joy86]. Basic understanding ofnetwork communication concepts is assumed; where required anyadditional ideas are introduced.The remainder of this document provides a description of the system internals, avoiding, when possi-ble, those portions which are utilized only by the interprocess communication facilities.2. OverviewIf we consider the International Standards Organization’s(ISO) Open System Interconnection (OSI)model of network communication [ISO81] [Zimmermann80], the networking facilities described here cor-respond to a portion of the session layer (layer 3) and all of the transport and network layers (layers 2 and1, respectively).The network layer provides possibly imperfect data transport services with minimal addressing struc-ture. Addressing at this levelisnormally host to host, with implicit or explicit routing optionally supportedby the communicating agents.At the transport layer the notions of reliable transfer,data sequencing, flowcontrol, and serviceaddressing are normally included. Reliability is usually managed by explicit acknowledgement of datadelivered. Failure to acknowledge a transfer results in retransmission of the data. Sequencing may be han-dled by tagging each message handed to the network layer by a sequence number and maintaining state atthe endpoints of communication to utilize receivedsequence numbers in reordering data which arrivesoutof order.The session layer facilities may provide forms of addressing which are mapped into formats requiredby the transport layer,service authentication and client authentication, etc. Various systems also provideservices such as data encryption and address and protocol translation.The following sections begin by describing some of the common data structures and utility routines,then examine the internal layering. The contents of each layer and its interface are considered. Certain ofthe interfaces are protocol implementation specific. Forthese cases examples have been drawn from theInternet [Cerf78] protocol family.Later sections coverrouting issues, the design of the rawsocket interfaceand other miscellaneous topics.3. GoalsThe networking system was designed with the goal of supporting multiple protocol families andaddressing styles. This required information to be ‘‘hidden’’incommon data structures which could bemanipulated by all the pieces of the system, but which required interpretation only by the protocols which‘‘controlled’’it. The system described here attempts to minimize the use of shared data structures to thosekept by a suite of protocols (a protocol family), and those used for rendezvous between ‘‘synchronous’’and‘‘asynchronous’’portions of the system (e.g. queues of data packets are filled at interrupt time and emptiedbased on user requests).Amajor goal of the system was to provide a framework within which newprotocols and hardwarecould be easily be supported. To this end, a great deal of effort has been extended to create utility routineswhich hide manyofthe more complexand/or hardware dependent chores of networking. Later sectionsdescribe the utility routines and the underlying data structures theymanipulate.SMM:18-4 Networking Implementation Notes4. Internal address representationCommon to all portions of the system are twodata structures. These structures are used to representaddresses and various data objects. Addresses, internally are described by the sockaddr structure,struct sockaddr {short sa_family; /* data format identifier */char sa_data[14]; /* address */};All addresses belong to one or more address families which define their format and interpretation. Thesa_family field indicates the address family to which the address belongs, and the sa_data field
View Full Document
Unlocking...