Choosing a transport
DisplayNet accepts the same commands over four transports. They differ in how you connect and how a reply reaches you.
| Transport | Where | Best for |
|---|---|---|
| Telnet | port 6980 | Control systems, scripting, anything already speaking a text protocol |
| SSH | the api account | The same session over an encrypted channel |
| WebSocket | ports 7000 / 7010 | Web applications that want a live session in the browser |
| REST | /api on 80 / 443 | HTTP integrations, generated clients, anything that prefers request/response |
Sessions and requests
The first three are one session: you open a connection, initialize it, and it stays open. Commands and replies flow both ways, and notifications arrive unprompted for as long as you hold it.
Each REST request is independent and carries its own token. There is nothing to initialize and nothing to hold open. When a REST client wants a live stream, it upgrades /api to a WebSocket.
The TCI WebSocket on 7000 / 7010 is a full API session, carrying the same commands and initialization as telnet. DisplayNet Manager uses this one.
The REST WebSocket, upgraded from /api on 80 / 443, is compatible with the SDVoE REST API and adds DisplayNet notifications on the same connection. Events start flowing the moment it connects, with no setup commands.
Shared behaviour
- The commands. Every command in the Command Reference works on the TCI interfaces. Most are also REST operations; the command map shows each command's REST form.
- The user model. One user store, one set of roles, one login token. See Authentication and permissions.
- The reply envelope. Every reply has the same
status/request_id/result/errorshape. - Requests and notifications. Asynchronous replies and state-change notifications behave the same way on every transport. See Requests and Events.