Thank you Moshe Zadka. What you're saying is that TCP connections can trigger ephemeral UDP pseudo-connections. The server communicates over just one UDP port, and data flow is bidirectional at all points in the chain. I'm not sure whether these facts affect the suggestion here. The mixmaster opens its own assigned UDP port to receive data from the server, as well as sending data to the server over another UDP port.

Make up your mind, telnet or raw? a Line-based protocol?

You're right, I should. Here is the scoop. For manual device tests I'm using PuTTY in its "raw" mode. That is the origin of "raw." Basically the telnet sessions are line-based command/response activity. The devices don't utilize the full telnet protocol, just a small subset. The terms "client" and "server" may be mixed up, from a networking standpoint. These are just conventions in the legacy software, right or wrong. The original authors called the Java app a server, and the devices clients. However the devices supply information that the Java app requests of them. So the actual roles are reversed. Normally, when talking to devices that know its protocol, the system is very simple. Here's how it works without a mixmaster script. The server initiates communications. The server broadcats a public query packet, and devices respond with their names and technical features. The server constructs a list of known devices. From there, the server invokes various device capabilities. When finished, the server shuts down the devices. Why the mixmaster? Many devices offer identical capabilites, but don't know the server's protocol. The mixmaster allows the server to use them. My apologies for confusing terminology and my thanks for your answers. Mark