lwip官方文档（英文） lwip移植优化必备

【实例简介】
Design and Implementation of the lwIP TCP/IP Stack lwip官方文档（英文），lwip移植优化必备 lwIP is an implementation of the TCP/IP protocol stack. The focus of the lwIP stack is to reduce memory usage and code size, making lwIP suitable for use in small clients with very limited resources such as embedded systems.
Abstract LWIP is an implementation of the TCP/IP protocol stack. The focus of the LWIP stack is to reduce memory usage and code size, making LwIP suitable for use in small clients with very linited resources such as embedded systeNs. II order to reduce processing anld meNory deIllanlds LwIP uses a tailor made APi that does not require any data copying This report describes the design and implementation of LwIP. The algorithms and data struc- tures used both in the protocol implementations and in the sub systems such as the memory and buffor managcmcnt systcms arc dcscribcd. Also included in this report is a rcfcrence manual for the lwIP API and some code examples of using IwIP Contents 1 Introduction 2 Protocol layering 3 Overview 4 Process model 5 The operating system emulation layer 6 Buffer and Menory management 6. 1 Packet buffers- pbufs 6.2 Memory managcmcnt 7 Network interfaces 8 IP processing 8.1 Receiving packets 8.2 Sending packets 335577788 8.3 Forwarding packets 8.4 ICMP D 1g 9 UDP processing 10 TCP processing 10.1 Overvi 9 10.2 Data structurcs 10.3 Sequence number calculations 10.4 Queuing and transmitting data 10.4.1Sill 10.5 Receiving segments 10.5. 1 Deimlultiple 10.5.2 Receiving data 10.6 Acccpting new connections 14 10.7 Fast retransmit 10.8 Timers 10.9 Round-trip time estimation 10.10Congestion control 15 11 Interfacing the stack 12 Application PrograIn Interface 16 12.1 Basic concepts 12.2 Implementation of the API 13 Statistical code analysis 17 13.1 Lines of code 18 13.2 Object code size 19 14 Performance analysis 15 API reference 21 15.1 Data types 15.1.1 Netbufs 15.2 Buffer functions 15.2.1 netbuf( 15.2.2 netbuf_delete( 15.2.3 nctbuf-() 15.2.4 netbuf free 15.2.5 netbuf-ref( 15.2. 6 netbuf_ler 15.2.7 netbuf_( 15.2.8 lletbuf_next( 15. 2.9 netbuf first() 15. 2.10 netbuf_copy( 15. 2.11 netbuf_chain() 15.2.12 net buf- fromaddro 15.2.13 net_ O 16 Network connection functions 25 16.0. 14 nctconn-newO 16.0.15 netcon delete().,,,,,,,, 16.0. 16 netconn-type() 16.0. 17 netconn-peer( 16.0. 18 netcon_addr() 16.0.19uetconll-bind( 16.0.20 netcon_connect( 26 16.0. 21 nctconn-listenO 26 16.0. 22 netcon _accept 26 16.0.23 netconn-recvO 60.0.24 netconn_write() 16.0.25 netcon_send( 16.0. 26 uetcolll_( 30 17 BSD socket library 0 17.1 The representation of a socket 17.2 Allocating a socket 30 17.2.1 The socket call 17.3 COllection setup 17.3.1 The bind( call 17.3.2 Thc connecto call 17.3.3 The listen call 32 17.3.4 The accept( call 17.4 Sending and receiving dat 17.4.1 The send( call 17.4.2 The sendto( alld sendmsgO) calls 17.4.3Th te call 17.4.4 The recv( and read calls 17.4.5 The recvfrom() and recvmsg() calls 18 Code examples 36 18.1 Using the API 36 18.2 Directly interfacing the stack Bibliography 41 2 PROTOCOL LAYERING 1 Introduction Over the last few vears, the interest for connecting computers and computer supported devices to wireless nctworks has steadily incrcascd. Computers are becoming morc and morc scamlcssly integratcd with everyday cquipmcnt and prices arc dropping. At the samc timc wireless networking technologies, such as Bluetooth [HNI98]and IEEE 802. 11b WLAN BIG+97: are emerging. This gives rise to many new fascinating scenarios in areas such as health care, safety and security, transportation, and processing industry. Small devices such as sensors can be connected to an existing network infrastructure such as the global Internet, and Monitored froI anywhere The Internet technology has proven itself flexible enough to incorporate the changing network environments of the past few decades. While originally developed for low speed networks such as the ARPANEt, the Internet technology today runs over a large spectrum of link technologies with vastly different characteristics in terms of bandwidth and bit error rate. It is highly advantageous to use the existing Internet technology in the wireless networks of tomorrow since a lar of applications using the Internet technology have been developed. Also, the large connectivity of the global Internet is a strong incentive Since sitall devices such as sensors are often required to be physically sinall and inexpensive, all implementation of the Internet protocols will have to deal with having limited computing resources and memory. This report describes the design and implementation of a small TCP/IP stack called LwIP that is small enough to bc uscd in minimal systcms This report is structured as follows. Sections 2, 3, and 4 give an overview of the LwIP stack Section 5 describes the operating system emulation layer, Section 6 describes the memory and buffer management. Section 7 introduces the network interface abstraction of lwiP. and sections 8,9, and 10 describe the implementation of the IP: UDP and TCP protocols. The Sections 11 nnd 12 describe how to interface with lwip and introduce the LWIP aPi. Sections 13 and 14 analyze the implementation. Finally, Section 15 provides a reference manual for the LWIP API and Scctions 17 and 18 show various codc examples 2 Protocol layering The protocols in the TCP/IP suite are designed in a layered fashion, where each protocol layer solves a scparate part of the communication problcm. This layering can scrvc as a guidc for designing the implementation of the protocols, in that each protocol can be implemented separately from the other. Implementing the protocols in a strict ly layered wa y can however, lead to a situation where the communication overhead between the protocol layers degrades the overall performance Cla82a]. To overcome these problems, certain internal aspects of a protocol can be Inade known to other protocols. Care Imust be taken so that only the iImportant information is shared among the layers Most TCP/IP implementations keep a strict division between the application layer and the lower protocol layers, whereas the lower layers can bc morc or loss intcrlcavcd. In most opcrating systems, the lower layer protocols are implemented as a part of the operating system kernel with entry points for communication with the application layer process. The application program is presented with an abstract view of the TCP/IP implementation, where network communication differs only very little from inter-process communication or file 1/o. The implications of this is that since the application prograIn is unaware of the bufer Ilechanisins used by the lower layers it cannot utilize this information to, e. g. reuse buffers with frequently used data. Also, when the application sends data, this data has to be copied from the application process'mcmory spacc into internal buffers before being processed by the network code. The operating systems used in minimal systems such as the target system of LwIP most often do not maintain a strict protection barrier between the kernel and the application processes. This allows using a more relaxed scheme for communication between the application and the lower layer protocols by the ineans of shared Menory. II particular, the application layer can be illade aware of the buffer handling mechanisms used by the lower layers. Therefore, the application can 4 PROCESS MODEL more efficiently reuse buffers. Also, since the application process can use the same memory as the networking code the application can read and write directly to the internal buffers, thus saving he expense of performing a copy. 3 Overview s in many other TCP/IP implementations, the layered protocol design has served as a guide for the design of the iImplementation of LWIP. Each protocol is iIlplernented as its owl Nodule with a few functions acting as entry points into each protocol. Even though the protocols are implemented separately, some layer violations are made, as discussed above, in order to improve performance both in terms of processing speed and memory usage. For example, when verifying the checksum of an incoming TCP segment and when demultiplexing a segment, the sourcc and destination IP addresses of the segment has to be known by the TCP module. Instead of passin g these addresses to tcp by the means of a function call. the tcp module is aware of the structure of the ip header, and can therefore extract this information by itself LWIP cOnsists of several nodules. Apart fromn the Nodules iMplementing the TCP/IP protocols (IP, ICMP, UDP, and TCP)a number of support lmodules are implelmented. The support nodules consists of the operating system emulation layer(described in Section 5), the buffer and memory management subsystems(describcd in Scction 6), nctwork interface functions(describcd in Scction 7), and functions for computing the Internet checksum. IWIP also includes an abstract API, which is described in Section 12 4 Process model The process model of a protocol implementation describes in which way the system has been di- vided into different processes. One process model that has been used to implement communication protocols is to let each protocol run as a stand alone process. With this model, a strict protocol layering is enforced, and the collInunication puints betweell the protocols Lust be strictly defined While this approach has its advantages such as protocols can be added at runtime, understanding the code and debugging is generally easier, there are also disadvantages. The strict layering is not, as dcscribcd carlicr, always the best way to implcment protocols. Also, and morc important for each layer crossed, a context switch must be made. For an incoming TCP segment this would mean three context switches, from the device driver for the network interface, to the IP process to the 'tcp process and finally to the application process. In most operating systems a context switch is fairly expensive Another collnon approach is to let the coMmnunication protocols reside in the kernel of the operating system. In the case of a kernel implementation of the communication protocols, the application processes communicate with the protocols through system calls. The communication protocols arc not strictly dividcd from cach other but may usc the techniques of crossing thc protocol layering LwIP uses a process model in which all protocols reside in a single process and are thus sep arated from the operating system kernel. Application programs may either reside in the LwIP process, or be in separate processes. Communication between the TCP/IP stack and the applica ion progralnls are done either by function calls for the case whlere the application progralll shares a process with LWIP, or by the means of a more abstract API Having LWIP implcmcntcd as a uscr spacc proccss rathcr than in the opcrating system kcrncl has both its advantages and disadvantages. The main advantage of having LwIP as a process is that is portable across different operating systems. Since LWIP is designed to run in small operating systems that generally do not support, neit her swapping out processes not virtual memory, the delay caused by having to wait for disk activity if part of the IwIP process is swapped or paged out to disk will not be a probleR. The problein of having to wait for a scheduling quantuM before getting a chance to service requests still is a problem however, but there is nothing in the design 6 BUFFER AND MEMORY MANAGEMENT of TwIP that precludes it from later being implemented in an operating system kernel 5 The operating system emulation layer In order to make LWIP portable, operating system specific function calls and data structures are not used direct y in the code. Instead, when such functions are needed the operating system emulation layer is used. The operating system emulation layer provides a uniform interface to operating systeIn services such as timers, process synchronization, and Inlessage passing InlechanisIns. In principle, when porting LwIP to other operating systems only an implementation of the operating system emulation layer for that particular operating system is needed The operating system emulation layer provides a timer functionality that is used by TCP. The timers provided by the opcrating systcm emulation laycr arc onc-shot timers with a granularity of at least 200 ms that calls a registered function when the time-out occurs The only process synchronization mechanism provided is semaphores. Even if semaphores are not avaliable in the underlying operating system they can be emulated by other synchronization primitives such as conditional variables or lock The Message passing is done through a siImple Inechallisll which uses all abstraction called mailboxes. A mailbox has two operations: post and fetch. The post operation will not block the proccss; rathcr, messages posted to a mailbox arc qucucd by the opcrating system emulation laycr until another process fetches them. Even if the underlying operating system does not have native support for the mailbox mechanism, they are easily implemented using semaphores 6 Buffer and memory management The memory and buffer management system in a communication system must be prepared to accommodate buffers of very varying sizes, ranging from buffers containing full-sized TCP segments with several hundred bytes worth of data to short ICMP echo replies consisting of only a few bytes Also, in order to avoid copying it should be possible to let the data content of the buffers reside inl IneInory that is not inalaged by the networking subsysteIll, such as application IneInlory or ROM 6.1 Packet buffers pbufs a pbuf is LwIP's internal representation of a packet, and is designed for the special needs of the minimal stack. Pbufs are similar to the mbufs used in the bsd implementations. The pbuf structurc has support both for allocating dynamic memory to hold packct contents, and for letting Pbufs can be linked togct list, called a pbuf chain t hat a packet may span over several pbufs Pbufs are of three types. PBUF-RAM, PBLF-ROM. and PBUF POOL. The pbuf shown in Figure 1 represents the PBUF-RAM type, and has the packet data stored in memory managed by the pbuf subsystem. The pbuf in Figure 2 is an exalmple of a chained pbuf, where the first pbuf in the chain is of the PBUF RAM type, and the second is of the PBUF- ROM type, which means that it has the data located in memory not managed by the pbuf system. The third type of pbuf PBUF-POOL, is shown in Figurc 3 and consists of fixcd sizc pbufs allocated from a pool of fixcd size pbufs. A pbuf chain may consist of multiple types of pbufs The three types have different, uses. Phufs of type PBUF-POOl: are mainly used by network device drivers since the operation of allocating a single pbuf is fast and is therefore suitable for use in all interrupt handler. PBUF-ROM Pbufs are used when all applicatiOn sends data that is located in memory managed by the application. This data may not be modified after the pbuf has been handed over to the TCP/IP stack and therefore this pbuf type main use is when the data is located in ROM(hence the name PBUF ROM). Headers that are prepended to the data in a Pbuf- ROM pbuf are stored in a Pbuf-RAM pbuf that is chained to the front ofof the PBUF ROM phut, as in Figure 2 6 BUFFER AND MEMORY MANAGEMENT 6.1 Packet buffers- pbufs Figurc 1.A PBUF- RAM pbuf with data in memory managed by the pbuf subsystem Figure 2. A PBUF RAM pbuf chained with a PBuF -ROM pbuf that has data in external memory. Pbufs of the PbUF_RAM type are also used when an application sends data that is dynamically generated. In this case, the pbuf system allocates memory not only for the application data, but also for the headers that will be prepended to the data. This is seen in Figure 1. The pbuf systern cannot know in advance what headers will be prepended to the data and assumes the worst case The size of the headers is configurable at compile time Q. In essence, incoming pbufs are of type PbuF POOL and outgoing pbufs are of the PBUF_roM or PBUF-RAM types The internal structure of a phuf can be seen in the figures 1 through 3. The pbuf structure consists of two pointers. two length fields, a fags field, and a reference count. The next field is a pointer to the next pbuf in case of a pbuf chain. The payload pointer points to the start of the data in the pbuf. The len field contains the length of the data contents of the pbuf. The tot_len field contains the sum of the length of the current pbuf and all len fields of following pbufs in the pbuf chain. In other words, the tot _len field is the sum of the len field and the value of the tot len ficld in the following pbuf in the pbuf chain. The flags ficld indicates the typc of the pbuf and the ref field contains a reference count. The next and pay load fields are native pointers and t he size of those varies depending on the processor architecture used. The two length fields 7 NETWORK INTERFACES 6.2 Memory management Figure 3. A chained PBUF- POol pbuf from the pbuf pool arc 16 bit unsigned integers and the flags and ref ficlds arc 4 bit widc. The total sizc of the buf structure depends on the size of a pointer in the processor architecture being used and on the smallest alignment possible for the processor architecture. On an architecture with 32 bit pointers and 4 byte alignment, the total size is 16 bytes and on an architecture with 16 bit pointers and 1 byte alignment, the size is 9 bytes The pbuf Nodule provides functions for manipulatioN of pbufs. Allocation of a pbuf is done by the function pbuf _alloc which can allocate pbufs of any of the three types described above The function pbuf_ref( incrcascs the rcfcrcncc count. Dcallocation is madc by the function pbuf_(), which first decreases the reference count of the pbuf. If the reference count reaches zero the pbuf is deallocated. The function pbuf_( shrinks the pbuf so that it occupies just enough memory to cover the size of the data. The tunction pbuf_header adJUStS payload pointer and the length fields so that a header can be prepended to the data in the pbuf The functions pbufchain(and pbuf_dechain( are used for chaining pbufs 6.2 Memory management, The memory manager supporting the pbuf scheme is very simple. It handles allocations and deallocations of contiguous regions of IlleImory and call shrink the size of a previously allocated memory block. The memory manager uses a dedicated portion of the total memory in the system his cnsurcs that the networking systcm docs not usc all of the availablc memory, and that the operation of other programs is not disturbed if the networking system has used all of it's memory Internally, the memory manager keeps track of the allocated memory by placing a small stru ture on top of each allocated memory block. This structure( Figure 4) holds two pointers to th next and previous allocation block in memory. It also has a used Hag which indicates whether the allocation block is allocated or Ilot Memory is allocated by searching the memory for an unused allocation block that is large enough for the requested allocation. The first-fit principle is used so that the first block that is large enough is uscd. When an allocation block is deallocated, the used flag is sct to zero. In ordcr to prevent fragmentation, the used fag of the next and previous allocation blocks are checked. If any of them are unused, the blocks are combined into one larger unused block 7 Network interfaces In LWIP device drivers for physical network hardwa.re are represented hy a network interface structure similar to that, in BsD. The network interface structure is shown in Figure 5. The network interfaces are kept on a global linked list, which is linked by the next pointer in the structure Each network interface has a name, stored in the name field in Figure 5. This two letter name identifies the kind of device driver used for the network interface and is only used when the 【实例截图】
【核心代码】