Chapter 86: TCP Advanced Features and Options

Chapter Objectives

After completing this chapter, students will be able to:

• Understand advanced TCP mechanisms like windowing, congestion control, Nagle’s algorithm, and keepalive.
• Identify key TCP socket options available in ESP-IDF (LwIP).
• Configure TCP socket options to optimize for specific application requirements (e.g., low latency, high throughput).
• Analyze the trade-offs associated with different TCP settings.
• Implement TCP keepalive to maintain and detect broken connections.
• Troubleshoot common issues related to TCP performance tuning on ESP32 devices.

Introduction

In the previous chapter, we explored the fundamentals of TCP socket programming, establishing reliable, connection-oriented communication. While the default TCP settings work well for many applications, scenarios often arise where fine-tuning TCP behavior is crucial for optimal performance, resource utilization, or specific application needs. This is particularly true for embedded systems like the ESP32, where resources such as memory and processing power are constrained.

This chapter delves into advanced TCP features and socket options that allow developers to influence how TCP connections operate. We will explore mechanisms like TCP windowing, congestion control, Nagle’s algorithm, and TCP keepalive. Understanding these features empowers you to tailor TCP communication for applications ranging from low-latency control systems to high-throughput data streaming, ensuring your ESP32-based networked devices perform efficiently and reliably.

Theory

The Transmission Control Protocol (TCP) is designed to provide reliable, ordered, and error-checked delivery of a stream of octets between applications running on hosts communicating over an IP network. To achieve this, TCP incorporates several sophisticated mechanisms. While many of these operate transparently, understanding them is key to effective tuning.

1. TCP Windowing (Sliding Window)

TCP uses a sliding window mechanism for flow control. It allows a sender to transmit multiple packets before waiting for an acknowledgment (ACK) from the receiver.

• Window Size: The receiver advertises a “receive window” (rwnd) to the sender. This value indicates the amount of data (in bytes) that the receiver is currently prepared to buffer for that connection.
• Sender’s Role: The sender can transmit up to the advertised window size of data without receiving an ACK. As data is acknowledged by the receiver, the window “slides” forward, allowing the sender to transmit more data.
• Impact: Larger window sizes can lead to higher throughput, especially on networks with high bandwidth-delay products (long fat networks). However, they also require more buffer memory on both the sender and receiver. On resource-constrained devices like the ESP32, managing buffer sizes effectively is critical.

2. TCP Congestion Control

IP networks are shared, and TCP employs congestion control mechanisms to prevent a single connection from overwhelming the network and to adapt to available network capacity. LwIP, the TCP/IP stack used in ESP-IDF, implements standard congestion control algorithms. Key phases include:

• Slow Start: When a connection begins, TCP starts by sending a small number of segments (typically 1 to 4, defined by the Initial Window, IW). For each ACK received, the congestion window (cwnd) is increased exponentially (usually doubled). This phase rapidly probes for available bandwidth.
• Congestion Avoidance: Once the cwnd reaches a certain threshold (the slow start threshold, ssthresh), TCP enters congestion avoidance. In this phase, cwnd increases linearly (e.g., by one segment per round-trip time, RTT) for each ACK received, probing for bandwidth more cautiously.
• Congestion Detection: TCP detects congestion primarily through two signals:
  • Timeout: If an ACK for a segment is not received within a certain timeout period, TCP assumes the segment (and potentially subsequent ones) was lost due to congestion.
  • Duplicate ACKs: If the sender receives three duplicate ACKs (acknowledging the same data), it infers that a segment was lost, and the receiver is requesting retransmission.
• Congestion Response (e.g., Reno, NewReno, CUBIC):
  • On timeout: cwnd is typically reset to 1 segment, ssthresh is set to half the cwnd value before loss, and TCP re-enters slow start.
  • On three duplicate ACKs (Fast Retransmit): TCP retransmits the missing segment without waiting for a timeout.
  • Fast Recovery: After a fast retransmit, cwnd is typically halved, ssthresh is set to this new cwnd, and TCP enters a phase to recover quickly without dropping back to slow start entirely.

LwIP’s specific congestion control algorithm can sometimes be configured or is set by default. Understanding these mechanisms helps in diagnosing performance issues that might be related to network congestion rather than device limitations.

graph TD
    %% Styles
    classDef startNode fill:#EDE9FE,stroke:#5B21B6,stroke-width:2px,color:#5B21B6;
    classDef processNode fill:#DBEAFE,stroke:#2563EB,stroke-width:1px,color:#1E40AF;
    classDef decisionNode fill:#FEF3C7,stroke:#D97706,stroke-width:1px,color:#92400E;
    classDef checkNode fill:#FEE2E2,stroke:#DC2626,stroke-width:1px,color:#991B1B;
    classDef endNode fill:#D1FAE5,stroke:#059669,stroke-width:2px,color:#065F46;

    A[Connection Starts]:::startNode --> B["Slow Start: <br> cwnd = Initial Window (IW) <br> Increase cwnd exponentially <br> e.g., double per RTT"]:::processNode
    B --> C{"cwnd < ssthresh?"}:::decisionNode

    C -- Yes --> B
    C -- No --> D["Congestion Avoidance: <br> Increase cwnd linearly <br> e.g., +1 MSS per RTT"]:::processNode

    D --> E{"Congestion Detected?"}:::decisionNode
    E -- No --> D

    E -- Yes --> F{"Type of Detection?"}:::decisionNode
    F -- Timeout --> G[Timeout Event Occurs]:::checkNode
    G --> H["Reset cwnd = 1 MSS <br> ssthresh = cwnd/2 (before loss) <br> Re-enter Slow Start"]:::processNode
    H --> B

    F -- "3 Duplicate ACKs" --> I[Fast Retransmit]:::checkNode
    I --> J["Fast Recovery: <br> Retransmit missing segment <br> cwnd = cwnd/2 <br> ssthresh = new cwnd <br> Continue in Congestion Avoidance-like state"]:::processNode
    J --> D

    %% Annotations
    subgraph Congestion States
        B
        D
        J
    end
    subgraph Congestion Events
        G
        I
    end

3. Nagle’s Algorithm

Nagle’s algorithm (defined in RFC 896) is a mechanism to reduce the number of small packets (often called “tinygrams”) sent over a network. It works as follows:

graph TD
    %% Styles
    classDef startNode fill:#EDE9FE,stroke:#5B21B6,stroke-width:2px,color:#5B21B6;
    classDef processNode fill:#DBEAFE,stroke:#2563EB,stroke-width:1px,color:#1E40AF;
    classDef decisionNode fill:#FEF3C7,stroke:#D97706,stroke-width:1px,color:#92400E;
    classDef endNode fill:#D1FAE5,stroke:#059669,stroke-width:2px,color:#065F46;
    classDef bufferNode fill:#FFF7ED,stroke:#A1887F,stroke-width:1px,color:#6D4C41;


    A[New data arrives from application]:::startNode --> B{Any previously transmitted data unacknowledged?}:::decisionNode

    B -- Yes --> C[Buffer new data]:::bufferNode
    C --> D{Is buffered data >= MSS <b>OR</b> <br> ACK for previous data received?}:::decisionNode
    D -- No --> C
    D -- Yes --> E["Send buffered data (now a larger segment)"]:::endNode

    B -- No --> F{Is new data < MSS?}:::decisionNode
    F -- Yes --> G["Send new data immediately (it's the first small segment in flight)"]:::endNode
    F -- No (data >= MSS) --> H["Send new data (full segment)"]:::endNode

• If there is new data to send, and previously transmitted data has not yet been acknowledged, the sender buffers the new data.
• The sender will only send the buffered data when either:
  1. A full-size segment (Maximum Segment Size – MSS) can be sent.
  2. An acknowledgment for the previously sent data is received.
• Purpose: To improve network efficiency by coalescing small outgoing messages into larger packets, reducing overhead (IP and TCP headers).
• Impact: While Nagle’s algorithm can improve overall throughput and reduce network congestion, it can introduce latency for applications that send small, frequent messages and require immediate responses (e.g., interactive applications like remote controls or Telnet-style interfaces). This is because the algorithm might delay sending a small packet, waiting for an ACK or more data.
• Disabling Nagle’s Algorithm: The TCP_NODELAY socket option can be used to disable Nagle’s algorithm for a specific connection. This is often necessary for latency-sensitive applications.

4. Delayed Acknowledgments (Delayed ACK)

Delayed ACK is a strategy used by TCP receivers to reduce protocol overhead. Instead of sending an ACK immediately for every received segment, the receiver may delay sending the ACK for a short period (e.g., up to 200ms, or until data is ready to be sent back in the same ACK packet).

• Purpose: To reduce the number of ACK packets, potentially “piggybacking” ACKs with data packets going in the reverse direction.
• Impact: Can improve efficiency but, in conjunction with Nagle’s algorithm, can exacerbate latency issues. For example, if a sender using Nagle’s algorithm sends a small piece of data and waits for an ACK, and the receiver uses delayed ACKs, the round trip for that small piece of data can be significantly delayed. If the sender has TCP_NODELAY set (Nagle disabled) and sends frequent small packets, the receiver might still delay ACKs, though the primary latency concern from Nagle is removed.

5. TCP Keepalive

TCP Keepalive is a mechanism to detect if a connection is still active, even if no data is being exchanged. This is useful for:

graph TD
    %% Styles
    classDef startNode fill:#EDE9FE,stroke:#5B21B6,stroke-width:2px,color:#5B21B6;
    classDef processNode fill:#DBEAFE,stroke:#2563EB,stroke-width:1px,color:#1E40AF;
    classDef decisionNode fill:#FEF3C7,stroke:#D97706,stroke-width:1px,color:#92400E;
    classDef checkNode fill:#FEE2E2,stroke:#DC2626,stroke-width:1px,color:#991B1B;
    classDef endNode fill:#D1FAE5,stroke:#059669,stroke-width:2px,color:#065F46;
    classDef timerNode fill:#FFF7ED,stroke:#A1887F,stroke-width:1px,color:#6D4C41;
    classDef errorNode fill:#FECACA,stroke:#B91C1C,stroke-width:2px,color:#7F1D1D;

    A[Connection Idle]:::startNode --> T1(Wait for TCP_KEEPIDLE period):::timerNode
    T1 --> B{TCP_KEEPIDLE expired?}:::decisionNode
    B -- No --> A
    B -- Yes --> C[Send Keepalive Probe 1]:::processNode
    C --> D{Probe Acknowledged?}:::decisionNode
    D -- Yes --> E[Connection Alive. Reset Idle Timer.]:::endNode
    E --> A

    D -- No --> P1(Probe Count = 1):::processNode
    P1 --> T2(Wait for TCP_KEEPINTVL period):::timerNode
    T2 --> F{TCP_KEEPINTVL expired?}:::decisionNode
    F -- No --> P1 
    F -- Yes --> G{Probe Count < TCP_KEEPCNT?}:::decisionNode
    
    G -- Yes --> H[Increment Probe Count. Send Next Keepalive Probe]:::processNode
    H --> D

    G -- No (Max Probes Sent) --> I[Connection Considered Dead]:::checkNode
    I --> J[Notify Application: <br> e.g., read/write fails with error]:::errorNode

    subgraph KeepaliveProbingLoop
        direction LR
        T1
        B
        C
        D
        P1
        T2
        F
        G
        H
    end

• Detecting Dead Peers: Identifying when the other end of a connection has crashed or become unreachable without properly closing the connection.
• Preventing Timeout by Intermediaries: Some firewalls or NAT devices might drop idle TCP connections after a certain period. Keepalive packets can keep the connection state active in these devices.
• How it Works: If a connection has been idle for a specified period (keepalive time), the system sends a keepalive probe packet to the peer.
  • If the peer responds, the connection is considered alive, and the timer resets.
  • If the peer does not respond after a certain number of probes (sent at a specific interval), the connection is considered broken, and the application is notified (e.g., read/write operations will fail).
• Parameters:

These parameters are configurable via socket options.

6. Socket Options for TCP Tuning

LwIP, through the standard Berkeley Sockets API, provides several socket options to control TCP behavior. These are typically set using the setsockopt() function.

The availability and exact behavior of some options can depend on the LwIP version and its compile-time configuration within ESP-IDF.

Practical Examples

Let’s explore how to use some of these TCP options in an ESP-IDF project. We’ll focus on TCP_NODELAY and SO_KEEPALIVE.

Assume you have a basic TCP client or server setup as described in Chapter 85. The following snippets show how to modify socket options after a socket is created but before connect() (for clients) or after accept() (for servers, on the new connection socket).

Example 1: Disabling Nagle’s Algorithm (TCP_NODELAY)

This is useful for applications requiring low latency for small, frequent messages.

#include "lwip/sockets.h"
#include "esp_log.h"

static const char *TAG = "tcp_nodelay_example";

// ... (socket creation code: int sock = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);)

// Assume 'sock' is a valid, created TCP socket descriptor
int optval = 1; // Enable TCP_NODELAY (disable Nagle's algorithm)
if (setsockopt(sock, IPPROTO_TCP, TCP_NODELAY, &optval, sizeof(optval)) < 0) {
    ESP_LOGE(TAG, "Error setting TCP_NODELAY: errno %d", errno);
    // Handle error: close socket, etc.
} else {
    ESP_LOGI(TAG, "TCP_NODELAY enabled.");
}

// ... (proceed with connect(), send(), recv(), close())

Example 2: Enabling and Configuring TCP Keepalive

This helps in detecting unresponsive peers or keeping connections alive through NATs.

#include "lwip/sockets.h"
#include "esp_log.h"

static const char *TAG = "tcp_keepalive_example";

// ... (socket creation code or accepted socket from server)
// Assume 'conn_sock' is a valid, connected TCP socket descriptor

int err;

// 1. Enable SO_KEEPALIVE
int keepalive_enable = 1;
err = setsockopt(conn_sock, SOL_SOCKET, SO_KEEPALIVE, &keepalive_enable, sizeof(keepalive_enable));
if (err < 0) {
    ESP_LOGE(TAG, "Error setting SO_KEEPALIVE: errno %d", errno);
    // Handle error
} else {
    ESP_LOGI(TAG, "SO_KEEPALIVE enabled.");

    // 2. Configure TCP_KEEPIDLE: Idle time before first probe (e.g., 60 seconds)
    int keepidle = 60; // Seconds
    err = setsockopt(conn_sock, IPPROTO_TCP, TCP_KEEPIDLE, &keepidle, sizeof(keepidle));
    if (err < 0) {
        ESP_LOGE(TAG, "Error setting TCP_KEEPIDLE: errno %d", errno);
        // Handle error
    } else {
        ESP_LOGI(TAG, "TCP_KEEPIDLE set to %d seconds.", keepidle);
    }

    // 3. Configure TCP_KEEPINTVL: Interval between probes (e.g., 10 seconds)
    int keepintvl = 10; // Seconds
    err = setsockopt(conn_sock, IPPROTO_TCP, TCP_KEEPINTVL, &keepintvl, sizeof(keepintvl));
    if (err < 0) {
        ESP_LOGE(TAG, "Error setting TCP_KEEPINTVL: errno %d", errno);
        // Handle error
    } else {
        ESP_LOGI(TAG, "TCP_KEEPINTVL set to %d seconds.", keepintvl);
    }

    // 4. Configure TCP_KEEPCNT: Number of probes before timeout (e.g., 3 probes)
    int keepcnt = 3;
    err = setsockopt(conn_sock, IPPROTO_TCP, TCP_KEEPCNT, &keepcnt, sizeof(keepcnt));
    if (err < 0) {
        ESP_LOGE(TAG, "Error setting TCP_KEEPCNT: errno %d", errno);
        // Handle error
    } else {
        ESP_LOGI(TAG, "TCP_KEEPCNT set to %d.", keepcnt);
    }
}

// ... (proceed with send(), recv(), close())

Tip: The exact names for keepalive parameters (TCP_KEEPIDLE, TCP_KEEPINTVL, TCP_KEEPCNT) might vary slightly across platforms, but LwIP in ESP-IDF generally supports these POSIX-standard or common Linux names. Always consult the LwIP documentation for the specific ESP-IDF version if unsure.

Example 3: Adjusting Send/Receive Buffer Sizes (Conceptual)

While SO_SNDBUF and SO_RCVBUF can be set, their effect in LwIP is more of a suggestion that influences LwIP’s internal window scaling and buffer management rather than directly allocating large socket-specific buffers as in traditional desktop OS networking. LwIP’s memory pool (pbufs) and global TCP configuration options (e.g., TCP_WND, TCP_SND_BUF in sdkconfig or LwIP options menu) play a more significant role.

#include "lwip/sockets.h"
#include "esp_log.h"

static const char *TAG = "tcp_buffer_example";

// ... (socket creation)
// Assume 'sock' is a valid TCP socket descriptor

// Suggest larger send buffer (e.g., 16KB)
// Note: LwIP will cap this based on its internal limits and available memory.
int sndbuf_size = 16 * 1024;
if (setsockopt(sock, SOL_SOCKET, SO_SNDBUF, &sndbuf_size, sizeof(sndbuf_size)) < 0) {
    ESP_LOGE(TAG, "Error setting SO_SNDBUF: errno %d", errno);
} else {
    ESP_LOGI(TAG, "SO_SNDBUF suggestion set to %d.", sndbuf_size);
    // You can use getsockopt to see what LwIP actually allowed.
    int actual_sndbuf;
    socklen_t optlen = sizeof(actual_sndbuf);
    getsockopt(sock, SOL_SOCKET, SO_SNDBUF, &actual_sndbuf, &optlen);
    ESP_LOGI(TAG, "Actual SO_SNDBUF is %d.", actual_sndbuf);
}

// Suggest larger receive buffer (e.g., 16KB)
int rcvbuf_size = 16 * 1024;
if (setsockopt(sock, SOL_SOCKET, SO_RCVBUF, &rcvbuf_size, sizeof(rcvbuf_size)) < 0) {
    ESP_LOGE(TAG, "Error setting SO_RCVBUF: errno %d", errno);
} else {
    ESP_LOGI(TAG, "SO_RCVBUF suggestion set to %d.", rcvbuf_size);
    int actual_rcvbuf;
    socklen_t optlen = sizeof(actual_rcvbuf);
    getsockopt(sock, SOL_SOCKET, SO_RCVBUF, &actual_rcvbuf, &optlen);
    ESP_LOGI(TAG, "Actual SO_RCVBUF is %d.", actual_rcvbuf);
}

// ... (proceed with connect(), send(), recv(), close())

To check LwIP’s actual TCP window and buffer sizes:

You can enable LwIP debug logs (Component config -> LWIP -> Enable LWIP Debug) and observe TCP state, or delve into LwIP statistics if enabled (LWIP_STATS). The actual effective window size is often dynamically managed by LwIP based on memory availability and flow control.

Build Instructions

1. Create Project: Start with a standard ESP-IDF project (e.g., copy a basic tcp_client or tcp_server example).
2. Add Code: Integrate the socket option settings into your TCP connection logic as shown above. Ensure you have the necessary includes: lwip/sockets.h and esp_log.h.
3. Configure Project:
   • Use idf.py menuconfig (or VS Code’s ESP-IDF Extension equivalent).
   • Ensure WiFi/Ethernet is configured correctly for network connectivity.
   • (Optional for Buffer Tuning): Component config -> LWIP -> TCP -> Default send buffer size and Default TCP receive window size. Modifying these global LwIP settings can have a broader impact than per-socket options for buffer sizes.
4. Build: idf.py build
5. Flash: idf.py -p (PORT) flash (replace (PORT) with your ESP32’s serial port).
6. Monitor: idf.py -p (PORT) monitor

Run/Flash/Observe Steps

1. Set up Network Environment:
   • Ensure your ESP32 can connect to a Wi-Fi network (for Wi-Fi examples) or Ethernet.
   • Have a peer application (e.g., a netcat/nc instance, a Python script, or another ESP32) to communicate with.
2. Observe Behavior:
   • TCP_NODELAY:
     • To observe the effect of TCP_NODELAY, you’d typically need a latency-sensitive application sending small packets.
     • Use a network sniffing tool like Wireshark on a machine on the same network.
     • With Nagle (default): Send multiple small chunks of data quickly. You might see them coalesced into fewer, larger packets.
     • With TCP_NODELAY enabled: Send the same small chunks. You should see more individual small packets being sent out more immediately.
     • Measure round-trip time for small messages if possible.
   • SO_KEEPALIVE:
     • Enable keepalive with a relatively short TCP_KEEPIDLE (e.g., 10-30 seconds for testing).
     • Establish a TCP connection.
     • Leave the connection idle. Observe Wireshark: you should see keepalive probe packets being sent from the ESP32 after TCP_KEEPIDLE seconds.
     • Test disconnection:
       1. Disconnect the peer abruptly (e.g., close the peer application without a graceful TCP close, or disconnect its network cable).
       2. The ESP32 will send TCP_KEEPCNT probes at TCP_KEEPINTVL intervals.
       3. After these probes go unacknowledged, subsequent send() or recv() calls on the ESP32 for that socket should fail (e.g., returning -1 with errno set to ETIMEDOUT or ECONNRESET). Your application logic should handle this.
   • Buffer Sizes:
     • Measuring the direct impact of SO_SNDBUF/SO_RCVBUF on ESP32 can be subtle due to LwIP’s internal management.
     • Throughput testing (sending a large amount of data and measuring time) under various network conditions (good vs. lossy) might show differences if LwIP’s effective window sizes are being influenced.
     • Monitor ESP32 RAM usage. Drastically increasing LwIP’s global buffer settings in menuconfig will consume more RAM.

Variant Notes

The TCP/IP stack (LwIP) and its socket API are largely consistent across the ESP32, ESP32-S2, ESP32-S3, ESP32-C3, ESP32-C6, and ESP32-H2 variants when using ESP-IDF. The core TCP mechanisms and socket options discussed behave similarly.

However, differences arise due to hardware capabilities and resource constraints:

• RAM Availability: Older variants like the original ESP32 have less RAM than newer ones like ESP32-S3. This directly impacts how large you can realistically set TCP buffers (via LwIP global config or SO_SNDBUF/SO_RCVBUF hints). Overly aggressive buffer settings can lead to memory exhaustion more quickly on variants with less RAM.
• CPU Performance: Faster CPUs on newer variants (e.g., dual-core ESP32, ESP32-S3) can handle higher network throughput and process TCP stack logic more quickly. This might mean they can benefit more from larger window sizes or sustain higher data rates.
• Network Interface:
  • Wi-Fi Performance: Different Wi-Fi chipsets/modules across variants might have varying raw Wi-Fi throughput capabilities, which can be a bottleneck regardless of TCP tuning.
  • Ethernet: Variants with built-in Ethernet MACs (some ESP32s, or via SPI-Ethernet modules) can offer more stable latency and higher throughput than Wi-Fi, influencing optimal TCP settings.
  • Thread/802.15.4 (ESP32-H2, ESP32-C6): When using TCP/IP over Thread, the network characteristics (lower bandwidth, potentially higher latency, smaller MTUs) are very different from Wi-Fi/Ethernet. TCP tuning strategies would need to adapt significantly (e.g., smaller default window sizes, careful use of Nagle).

General Guidance:

• Start with default LwIP settings.
• Tune cautiously, one parameter at a time, and measure the impact.
• Always monitor RAM usage (esp_get_free_heap_size()) when adjusting buffer-related settings, especially on RAM-constrained variants.
• The principles of TCP tuning are universal, but the optimal values will depend on the specific ESP32 variant, the network environment, and the application’s requirements.

Common Mistakes & Troubleshooting Tips

Warning: Always test TCP tuning changes thoroughly in a realistic network environment that mirrors your deployment scenario. Changes that improve performance in one scenario might degrade it in another.

Exercises

1. Nagle’s Algorithm Latency Test:
   • Create a TCP server (e.g., on your PC using Python or netcat) that echoes back any data it receives.
   • Write an ESP32 TCP client application that connects to this server.
   • Implement a function that sends a small message (e.g., 10 bytes) to the server and waits for the echo. Measure and print the round-trip time (RTT).
   • Run this test multiple times with Nagle’s algorithm enabled (default) and then with TCP_NODELAY set to 1.
   • Average the RTTs for both cases. Does disabling Nagle’s algorithm significantly reduce RTT for these small messages? Document your findings.
2. TCP Keepalive Verification:
   • Modify the ESP32 TCP client or server from a previous example to enable SO_KEEPALIVE.
   • Set TCP_KEEPIDLE to 20 seconds, TCP_KEEPINTVL to 5 seconds, and TCP_KEEPCNT to 3.
   • Establish a connection with a peer.
   • Use Wireshark to observe network traffic. Verify that keepalive probes start after 20 seconds of inactivity.
   • Abruptly terminate the peer application or disconnect its network interface.
   • Observe in Wireshark that the probes go unanswered.
   • Verify that after approximately 20 + (3 * 5) = 35 seconds, read/write operations on the ESP32 socket fail, and your application detects the broken connection. Log the errno.
3. Throughput vs. LwIP Buffer Configuration:
   • Write an ESP32 TCP client that sends a large amount of data (e.g., 1MB) to a TCP server (e.g., iperf or a custom server that discards data).
   • Measure the time taken and calculate the throughput.
   • Run this test with default LwIP TCP window/buffer settings (Component config -> LWIP -> TCP).
   • Modify the Default TCP receive window size and Default send buffer size in menuconfig (e.g., try halving them, then try increasing them slightly if RAM allows). Rebuild and re-flash.
   • Re-run the throughput test. How do these global LwIP settings affect measured throughput and ESP32 RAM usage (esp_get_free_heap_size())? Document your observations. (Be cautious with increasing values to avoid out-of-memory errors).
4. Research an Additional Socket Option:
   • The SO_LINGER socket option controls the behavior of the close() system call when there is unsent data in the socket send buffer.
   • Research how SO_LINGER works (l_onoff and l_linger fields of the linger struct).
   • Explain a scenario where configuring SO_LINGER might be useful for an ESP32 application.
   • Write a small code snippet demonstrating how to set SO_LINGER on an ESP32 socket.

Summary

• TCP provides reliable communication through mechanisms like windowing for flow control and congestion control (slow start, congestion avoidance) to adapt to network conditions.
• Nagle’s Algorithm reduces overhead by coalescing small packets but can add latency; TCP_NODELAY disables it for low-latency needs.
• Delayed ACKs by receivers can also impact latency in conjunction with Nagle’s.
• TCP Keepalive (SO_KEEPALIVE, TCP_KEEPIDLE, TCP_KEEPINTVL, TCP_KEEPCNT) helps detect dead connections and maintain connections through NATs/firewalls.
• Socket options like SO_SNDBUF and SO_RCVBUF can hint at buffer sizes, but LwIP’s global configuration and memory management are key on ESP32.
• Tuning TCP involves trade-offs (e.g., latency vs. throughput, CPU/memory usage vs. performance).
• The behavior of these TCP features is generally consistent across ESP32 variants, but resource constraints (RAM, CPU) influence optimal tuning parameters.
• Always test tuning changes thoroughly and monitor system resources.

Further Reading

• ESP-IDF Programming Guide:
  • Socket Options: https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/lwip.html
• LwIP Project Documentation:
  • LwIP Wiki & Documentation: http://lwip.wikia.com/wiki/LwIP_Wiki (General LwIP info)
• RFCs (Request for Comments) – The definitive sources for TCP:
  • RFC 793: Transmission Control Protocol (TCP) https://www.rfc-editor.org/rfc/rfc793.html
  • RFC 896: Nagle Algorithm (Congestion Control in IP/TCP Internetworks): https://www.rfc-editor.org/rfc/rfc896.html
  • RFC 1122: Requirements for Internet Hosts — Communication Layers (Sections on TCP, including Keepalive): https://www.rfc-editor.org/info/rfc1122
• Books:
  • “TCP/IP Illustrated, Vol. 1: The Protocols” by W. Richard Stevens – A classic and comprehensive reference.