Module monitor 

Single-reflector XLX UDP JSON monitor client.

Each XlxMonitor manages a single UDP socket connected to one XLX reflector’s monitor port (10001). The lifecycle is:

1. Connect: XlxMonitor::connect binds a local UDP socket, sends the "hello" handshake datagram, and returns the monitor handle.

2. Receive: XlxMonitor::recv awaits the next UDP datagram with a 30-second timeout, parses the JSON payload via protocol::parse, and returns the decoded MonitorMessage. A timeout returns None, signaling that the reflector may be unresponsive.

3. Disconnect: drop the monitor. The Drop implementation sends a best-effort "bye" datagram so the reflector can clean up its client entry promptly rather than waiting for a timeout.

Single-client limitation

Each XLX reflector monitor port accepts connections from any client, but each XlxMonitor instance talks to exactly one reflector. To monitor multiple reflectors, the orchestrator in super::run manages a pool of monitors.

Timeout behavior

The 30-second recv timeout is chosen to be 3x the xlxd update period (~10 seconds). If no data arrives within this window, the reflector is likely down or the network path is broken. The orchestrator can then decide to reconnect or replace the monitor.

UDP socket binding

Each monitor binds to 0.0.0.0:0 (ephemeral port) because the XLX monitor protocol is stateless from the server’s perspective — the server tracks clients by source address, and each monitor needs its own port to avoid datagram interleaving.

Structs

XlxMonitor 🔒

A UDP client connected to a single XLX reflector’s monitor port.

Constants

MAX_DATAGRAM_SIZE 🔒

Maximum UDP datagram size for the XLX monitor protocol.

RECV_TIMEOUT 🔒

Recv timeout: 3x the xlxd ~10-second update period.

XLX_MONITOR_PORT 🔒

XLX monitor port as defined by the xlxd source code.