Broadcast serial device data via UDP

Create a UDP connection on the machine attached to the device and set its destination to your network's broadcast address — the all-ones host address for your subnet (for a 255.255.255.0 mask that's the .255 address of your range) — together with the UDP port your listeners will use. Any machine on that subnet with an application listening on that port then receives the data, with no per-listener setup required on their side.

A couple of practical points: on a host with multiple network interfaces, set the broadcast for the specific network you intend, so you're not sending onto the wrong segment; and pick a port that isn't already in use by something else on the subnet. The exact broadcast address depends on your subnet mask, so base it on your actual network configuration rather than a fixed value.

Answered by Bohdan Miniv · QA Engineering

Yes, with a couple of approaches depending on what "several destinations" means. If you want every machine on the local segment to receive the data, a single broadcast (previous question) is the simplest way — one datagram the network delivers to all listeners on the port. If you want a specific set of destinations, you can direct UDP to particular addresses, and for a defined group across a properly configured network, multicast is the purpose-built option.

Two honest limits shape the choice. Broadcast does not cross routers — it stays within the local subnet — so "several destinations" on other subnets or over the internet can't be reached by broadcast; you'd use addressed (unicast) UDP to each, or TCP. And UDP gives no delivery guarantee to any of them, so if all recipients must reliably receive every message, UDP is the wrong transport regardless of how you address it.

Answered by Nikolai Svarachevsky · Lead Developer

RFC 2217 is a set of extensions to Telnet, and Telnet runs over TCP because the port-control negotiation depends on TCP's guarantees. Setting a baud rate or toggling a signal line is done with in-band commands that must arrive reliably and in order, and the two ends acknowledge each other as they negotiate. That's inherently a connection-oriented exchange.

UDP provides no connection, no ordering, and no guaranteed delivery — a command could be dropped or arrive out of sequence with the data it was meant to accompany, which would leave the two ends disagreeing about the port state. So UDP in SEC is strictly for carrying raw data, typically one-way broadcast; anything that needs parameter or signal control runs over TCP in Telnet mode. The transport and the feature set go together by necessity.

Answered by Nikolai Svarachevsky · Lead Developer

Use SEC's packetization controls to accumulate bytes before they go out. You can hold data until a specific delimiter character arrives, until a set time has elapsed, or until a block reaches a chosen size — then SEC emits the collected bytes as one datagram instead of dribbling them out in fragments. For a message-oriented protocol, triggering on the end-of-message character is usually the cleanest way to get one message per packet.

One thing to keep in mind that's specific to UDP: a datagram larger than the network's MTU will be IP-fragmented, and with UDP the loss of any fragment discards the whole datagram. So aim to have each accumulated message fit within a single MTU-sized packet where you can, rather than building very large datagrams. Small, self-contained messages are what UDP handles best.

Answered by Nikolai Svarachevsky · Lead Developer