Introduction to LwIP from Baidu Encyclopedia: https://baike.baidu.com/item/lwip/10694326

lwip is a small open source TCP / IP protocol stack developed by Adam Dunkels of the Swedish Institute of Computer Science (SICS) . The focus of the implementation is to reduce RAM usage while maintaining the main functions of the TCP protocol.

LwIP is Light Weight (light weight) IP protocol, can run with or without operating system support. The focus of LwIP implementation is to reduce the RAM occupation while maintaining the main functions of the TCP protocol. It only needs a dozen KB of RAM and about 40K of ROM to run, which makes the LwIP protocol stack suitable for low-end embedded systems. Use.

The lwIP protocol stack mainly focuses on how to reduce memory usage and code size, so that lwIP can be applied to small platforms with limited resources such as embedded systems. In order to simplify the processing and memory requirements, lwIP has cut down the API, so you don't need to copy some data.

The RAW API puts the protocol stack and the application in a process. This interface is based on the function callback technology, and applications that use this interface do not need to perform continuous operations. However, this makes the application writing more difficult and the code difficult to understand. In order to receive data, the application registers a callback function with the protocol stack. The callback function is associated with a specific connection. When the associated connection reaches a packet, the callback function is called by the protocol stack. This has both advantages and disadvantages. The advantage is that since the application and the TCP / IP protocol stack reside in the same process, there is no process switching when sending and receiving data. The main disadvantage is that the application cannot trap itself in a long-term continuous operation, which will lead to a decrease in communication performance, because TCP / IP processing and continuous operation cannot occur in parallel. This shortcoming can be overcome by dividing the application into two parts, one part for communication and one part for calculation.

The lwip API puts reception and processing in a thread. In this way, as long as the processing flow is slightly delayed, the reception will be blocked, which directly causes serious problems such as frequent packet loss and unresponsive response. Therefore, reception and protocol processing must be separated. The author of LwIP has obviously taken this into consideration. He provided us with the tcpip_input () function to deal with this problem, although he did not explain it in the rawapi article. Speaking of which, readers should know the answer to where the messages delivered by the tcpip_input () function come from. Yes, they come from the receiving thread composed of the underlying network driver. When we write a network driver, its receiving part is created in the form of a task. After the data packet arrives, remove the Ethernet packet header to get the IP packet, and then directly call the tcpip_input () function to deliver it to the mbox mailbox. After the delivery is completed, the receiving task continues to receive the next data packet, and the delivered IP packet will continue to be processed by the TCPIP thread. In this way, even if the processing time of an IP packet is too long, it will not cause frequent packet loss. This is the lwip API.

The BSD API provides a UNIX standard API based on the open-read-write-close model. Its biggest feature is that it is easier to port applications to other systems, but it is relatively inefficient in embedded systems and takes up more resources. This is sometimes intolerable for our embedded applications.