Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
LIGHTWEIGHT IP
#1

INTRODUCTION
lwIP is a small independent implementation of the TCP/IP protocol
suite that has been developed by Adam Dunkels at the Computer and
Networks Architectures (CNA) lab at the Swedish Institute of Computer
Science (SICS). The focus of the lwIP TCP/IP implementation is to reduce resource usage while still having a full scale TCP. This making lwIP suitable for use in embedded systems with tenths of kilobytes of free RAM and room for around 40 kilobytes of code ROM.
As in many other TCP/IP implementations, the layered protocol design has served as a guide for the design of the implementation of lwIP. Each protocol is implemented as its own module, 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 source and destination IP addresses of the segment has to be known by the TCP module. Instead of passing 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.
It uses a tailor made API that does not require any data copying. It includes the following sub modules that are not present in TCP/IP
a. The operating system emulation layers
b. Buffer and memory management
c. Network interfaces
d. Application program interface

FEATURES
IP (Internet Protocol) including packet forwarding over multiple network interface
ICMP (Internet Control Message Protocol) for network maintenance and debugging
UDP (User Datagram Protocol) including experimental UDP-lite extensions
TCP (Transmission Control Protocol) with congestion control, RTT estimation and fast recovery/fast retransmit
Specialized raw API for enhanced performance
Optional Berkeley-alike socket API
Do not maintain a strict layer. More relaxed scheme for communication between layers.(By means of shared memory)
UDP (User Datagram Protocol) including experimental UDP-lite extensions
Application process can use the same memory as the networking code. Application can read and write directly to the internal buffers and saving the expense of performing a copy.
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 means of shared memory. In particular, the application layer can be made aware of the buyer handling mechanisms used by the lower layers. Therefore, the application can more anciently reuse buyers. Also, since the application process can use the same memory as the networking code the application can read and write directly to the internal buyers, thus saving the expense of performing a copy.

PROCESS MODEL
The process model of a protocol implementation describes in which way the system has been di-vided into deferent 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 communication points between the protocols must 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 described earlier, always the best way to implement protocols. Also, and more 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.

The communication protocols are not strictly divided from each other but may use the techniques of crossing the protocol layering.lwIP uses a process model in which all protocols reside in a single process and are thus separated 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 application programs are done either by function calls for the case where the application program shares process with lwIP, or by the means of a more abstract API. Having lwIP implemented as a user space process rather than in the operating system kernel has both its advantages and disadvantages. The main advantage of having lwIP as a process is that is portable across deferent operating systems. Since lwIP is designed to run in small operating systems that generally do not support neither swapping out processes not virtual memory, the delay caused by having to wait for disk activity if part of the lwIP process is swapped or paged out to disk will not be a problem. The problem 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 of lwIP that precludes it from later being implemented in an operating system kernel

All protocols reside in a single process thus are separated from the OS kernel
This allows portability across different OS.
APP may either reside in the LWIP process or be in separate processes.
Communications are done by function calls.
Or using a more abstract API.
Reply



Forum Jump:


Users browsing this thread:
1 Guest(s)

Powered By MyBB, © 2002-2024 iAndrew & Melroy van den Berg.