painlessmesh::tcp Namespace Reference

Classes
class	BufferedConnection
struct	TcpRetryConfig

Functions
void	scheduleAsyncClientDeletion (Scheduler *scheduler, AsyncClient *client, const char *logPrefix)
uint32_t	retryBackoffDelay (const TcpRetryConfig &cfg, uint8_t retryCount)
TcpRetryConfig	clampTcpRetryConfig (TcpRetryConfig cfg)
uint32_t	encodeNodeId (const uint8_t *hwaddr)
uint32_t	decodeNodeIdFromIP (IPAddress ip)
template<class T , class M >
void	initServer (AsyncServer &server, M &mesh)
template<class T , class M >
void	connect (AsyncClient &client, IPAddress ip, uint16_t port, M &mesh, uint8_t retryCount=0)

Variables
uint32_t	lastScheduledDeletionTime = 0
painlessmesh::buffer::temp_buffer_t	shared_buffer

Function Documentation

clampTcpRetryConfig()

TcpRetryConfig painlessmesh::tcp::clampTcpRetryConfig ( TcpRetryConfig  cfg )

inline

Coerce a retry configuration into safe operating bounds

Only the two values that can render a node unusable are clamped: maxRetries (heap/recursion pressure) and retryDelayMs (hot-loop floor and overflow ceiling). maxRetries == 0 is explicitly allowed - it means "fall back to a WiFi reconnect on the first TCP error", which is the whole point of the low-latency profile. stabilizationDelayMs, exhaustionReconnectDelayMs and failureBlockDurationMs are left alone because 0 is meaningful for each (skip stabilization / reconnect immediately / never blocklist).

Parameters

cfg	Configuration to clamp (taken by value, returned clamped)

Returns

The clamped configuration

connect()

template<class T , class M >

void painlessmesh::tcp::connect	(	AsyncClient &	client,
		IPAddress	ip,
		uint16_t	port,
		M &	mesh,
		uint8_t	retryCount = 0
	)

Establish TCP connection with retry mechanism and exponential backoff

This function attempts to connect to the mesh network via TCP. If the connection fails (error -14 ERR_CONN or other errors), it will retry up to the configured maxRetries times before triggering a full WiFi reconnection cycle. See Mesh::setTcpRetryConfig() to tune the retry envelope; the defaults reproduce the historic hardcoded behaviour.

The retry mechanism helps handle timing issues where:

• The TCP server may not be immediately ready after AP initialization
• Network stack may need time to stabilize after IP acquisition
• Transient network conditions may cause temporary connection failures
• Multiple nodes connecting simultaneously may cause temporary overload

Exponential backoff is used to increase delay between retries, which:

• Gives the TCP server more time to recover from overload
• Reduces network contention when multiple nodes are retrying
• Improves overall connection success rate in congested networks

Parameters

client	AsyncClient to use for connection
ip	Target IP address
port	Target port
mesh	Reference to mesh instance for callbacks
retryCount	Current retry attempt (default 0, used internally for recursion)

decodeNodeIdFromIP()

uint32_t painlessmesh::tcp::decodeNodeIdFromIP ( IPAddress  ip )

inline

encodeNodeId()

uint32_t painlessmesh::tcp::encodeNodeId ( const uint8_t *  hwaddr )

inline

initServer()

template<class T , class M >

void painlessmesh::tcp::initServer	(	AsyncServer &	server,
		M &	mesh
	)

retryBackoffDelay()

uint32_t painlessmesh::tcp::retryBackoffDelay ( const TcpRetryConfig &  cfg, uint8_t  retryCount  )

inline

Delay before retry attempt number retryCount

Exponential backoff with the multiplier capped at 8, giving the default sequence 1s, 2s, 4s, 8s, 8s. Capping prevents excessive delays and keeps the product clear of uint32_t overflow.

Parameters

cfg	Active retry configuration
retryCount	Zero-based retry attempt number

Returns

Delay in milliseconds

scheduleAsyncClientDeletion()

void painlessmesh::tcp::scheduleAsyncClientDeletion ( Scheduler *  scheduler, AsyncClient *  client, const char *  logPrefix  )

inline

Schedule deletion of an AsyncClient with proper spacing to prevent concurrent cleanups

This function ensures that AsyncClient deletions are spaced out in time to prevent the AsyncTCP library's internal cleanup routines from interfering with each other.

When multiple AsyncClient objects need to be deleted (e.g., during high connection churn or sendToInternet scenarios), scheduling them all with the same delay can cause them to execute concurrently, leading to heap corruption.

This function maintains a global timestamp of when the last deletion was scheduled and calculates an appropriate delay for the new deletion to ensure adequate spacing.

Parameters

scheduler	The task scheduler to use for scheduling the deletion
client	The AsyncClient pointer to delete
logPrefix	Prefix for the log message (e.g., "~BufferedConnection" or "tcp_err")

Variable Documentation

lastScheduledDeletionTime

uint32_t painlessmesh::tcp::lastScheduledDeletionTime = 0

shared_buffer

painlessmesh::buffer::temp_buffer_t painlessmesh::tcp::shared_buffer