When you're wiring up a Cueva Control flow to talk to a third-party device (a DSP, a video matrix, a lighting console) you'll usually have a choice: TCP or UDP. The right answer depends on what you're asking that connection to do.

TCP: reliable, ordered, slower

TCP guarantees delivery. Every packet is acknowledged; if one gets lost the connection retransmits it. This makes TCP the right choice for sending commands where you need to know they arrived: fader positions, routing changes, firmware updates. The tradeoff is latency: that acknowledgement round-trip adds overhead.

UDP: fast, fire-and-forget

UDP has no handshake and no acknowledgement. Packets are sent and forgotten. This makes it ideal for high-frequency data like ArtNet DMX frames, OSC control messages, and audio metering. A lost frame is better than a delayed one.

The practical rule

  • Use TCP for command/response protocols (Q-SYS, Modbus, Amate Audio Xcellence)
  • Use UDP for streaming data (ArtNet, OSC, sACN)
  • Use TCP when the receiving device expects a persistent connection
  • Use UDP for broadcast discovery and one-way notifications

In Cueva Control, both TCP Send and UDP Send nodes support variable substitution. You can inject flow variables like scene IDs or GPIO states directly into your command strings.

WebSocket: TCP with extras

WebSocket builds on TCP and adds a persistent, full-duplex channel with a browser-compatible framing protocol. Use it when you're communicating with a web dashboard, a React app, or any service that expects WS rather than raw TCP.