There are three different APIs which may be used by applications to interface with the
stack: the raw API, the sequential API, or the BSD sockets compatibility API. Each one
in turn builds on the functionality provided by the previous API. This allows users
the flexibility of choosing a fairly bare implementation to squeeze the maximum out
of the available resources; or to use a more powerful API to simplify application
coding and reduce time-to-market. Note that despite the presence of the BSD
sockets compatibility API, the lwIP stack implementation is not in any way related to
the other BSD-derived TCP/IP stacks present in eCos.
The raw API provides an event-based interface with callbacks directly into the
application in order to handle incoming/outgoing data and events. There is no
inter-thread protection and can only operate with a single thread of execution.
The sequential API is a more traditional style of network interface API which
provides functions that may be called synchronously to perform network
operations, and where those operations can be considered complete (or will
complete asynchronously with no further application interaction) when those
functions return to the application.
When using the sequential API (or the BSD sockets API which is layered on top of
it), lwIP maintains its own internal thread for network data processing and event
management. This is usually referred to as lwIP's TCP/IP thread (even though that
is a slight misnomer). This thread uses mailboxes to communicate with application
threads, and semaphores to provide mutual exclusion protection.
The BSD sockets compatibility API included in lwIP provides a subset of the
Berkeley sockets interface introduced in the BSD 4.2 operating system. The
Berkeley sockets interface, recently standardised by ISO/IEC in POSIX 2003.1,
will be familiar to those who have developed network applications on Linux,
POSIX, UNIX or to a limited extent Windows with Winsock.
As the BSD sockets API provided as part of lwIP is only a subset of the full
sockets, it should be considered only as an aid to development or for when
porting existing code. It should not be considered as a drop-in replacement for
applications written for a complete BSD network stack implementation which
supports a wealth of features that do not exist in, and in many cases would be
inappropriate for, a low footprint implementation such as lwIP.