Raw UDP Nodes
UDP is the transport for equipment that broadcasts rather than converses: discovery probes, syslog-style status pushes, telemetry beacons, simple command datagrams. The raw UDP nodes give a pipeline a datagram socket to those devices.
There are two nodes. Setting up the connection they send through (host, port, timeouts, datagram size, the egress guard) is covered in the UDP connector guide.
Configuration Quick Reference
| Field | What you choose | Details |
|---|---|---|
| Parameters | Connection, Function, Function Parameters, Timeout Override | Select the UDP connection profile, the function, its parameters (with expression support), and optionally a per-call timeout. |
| Settings | Description, Timeout (seconds), Retry on Timeout, Retry on Fail, On Error | Node description, maximum execution time, retry behavior, and error handling. All execution settings default to pipeline-level values. |
The two nodes
| Node | Purpose | Common Use Cases |
|---|---|---|
| UDP Send | Fire a datagram and return immediately | Wake-on-LAN style commands, status pushes, beacon triggers |
| UDP Request | Send a datagram, then wait for one reply | Discovery probes, simple query/answer command sets |
Every call opens its own ephemeral source socket — UDP is connectionless, so there is no session to hold and no reconnect to wait for.
Encoding
The function's Encoding decides how bytes appear as text, exactly as on the TCP nodes: utf8/ascii for text protocols, hex or base64 for binary ones, bytes for raw passthrough.
Output
Each UDP node delivers its data under result, and execution facts (success, functionId, durationMs, timestamp) under _metadata:
| Node | Expression | Description |
|---|---|---|
| UDP Send | $node["Name"].result.bytesWritten | How many bytes the OS accepted for transmission |
| UDP Request | $node["Name"].result.data | The reply datagram, encoded as the function's encoding says |
$node["Name"].result.bytesWritten | How many bytes the request datagram carried | |
$node["Name"].result.bytesRead | How many bytes of the reply were kept | |
$node["Name"]._metadata.truncated | true when the reply was longer than Max Response Bytes and the tail was dropped — a fact about the call, so it rides with the execution facts | |
$node["Name"]._metadata.method, $node["Name"]._metadata.connectionId, $node["Name"]._metadata.protocol, $node["Name"]._metadata.endpoint | The call's other facts, on both nodes: the operation, the connection it ran over, udp, and the host:port the datagram went to | |
$node["Name"].result.sourceHost | The IP the reply came from — present when the socket reported a source address | |
$node["Name"].result.sourcePort | The port the reply came from |
UDP has no handshake and no acknowledgement. result.bytesWritten says the operating system accepted the datagram for transmission — the peer may be offline, firewalled, or silently dropping it, and the node still reports success. If you need to know the device heard you, use UDP Request and treat the reply as the receipt.
Any host can answer a datagram. When the reply matters, compare $node["Name"].result.sourceHost against the address you expected before acting on result.data.
A reply larger than Max Response Bytes is cut, and _metadata.truncated is true. Branch on it rather than parsing a half message — raising the limit, or asking the device for a smaller response, are the two real fixes.