What is the sockets API and how does it map to embedded networking?

The sockets API (Berkeley sockets, POSIX sockets) is the standard programming interface for network communication. A socket is a file-descriptor-like handle representing one endpoint of a communication channel. The basic flow for a TCP server is: socket() to create the endpoint, bind() to assign a local address and port, listen() to mark it as a server socket, accept() to wait for incoming connections (returning a new socket for each client), and send()/recv() to exchange data. A TCP client calls socket(), then connect() to reach the server, then send()/recv(). For UDP, there is no connection — you use sendto() and recvfrom() with explicit addresses.

On embedded Linux, you use the exact same POSIX sockets API as on a desktop — #include <sys/socket.h> and link against libc. The kernel handles the TCP/IP stack. On bare-metal/RTOS with lwIP, you have two options: the "netconn" or "socket" API that closely mirrors POSIX sockets (with blocking calls in a threaded environment), or the "raw" API that uses callbacks (your function is called when data arrives, with no threads required). The raw API is more efficient but harder to program.

The critical embedded consideration is non-blocking I/O and multiplexing. A blocking recv() ties up a thread waiting for data. On a desktop system with plenty of RAM, you might spawn a thread per connection. On an embedded system with 10 KB stacks and limited threads, you use non-blocking sockets with select(), poll(), or (on Linux) epoll() to handle multiple connections in a single thread. Frameworks like libevent or libev abstract this for embedded Linux. On RTOS systems, lwIP's raw API inherently works this way — callbacks are invoked from the network thread without blocking.