Managing live WebSocket API clients
[Zato-based]/en/docs/3.2/index.html WebSockets are a great choice for high-performance [API integrations]/en/docs/3.2/intro/esb-soa.html). WebSockets have minimal overhead, which, coupled with their ability to invoke services in a synchronous manner, means that large numbers of clients can easily connect to Zato API servers.
Introduction
The crucial distinction between WebSockets and typical REST-based APIs is that clients based on the former protocol always establish long-running TCP connections and, once connected, the overhead they incur is practically negligible.
With a great number of clients a series of questions naturally appears. What are the clients currently connected? What if I want to force one to disconnect? What topics and message queues are they subscribed to? How can I communicate with the WebSockets directly from the Zato Dashboard?
This blog post answers all these questions and then some more.
WebSocket channels
As a refresher, recall that all WebSocket clients connect to Zato through their channels. Each channel encapsulates basic information about what is expected from each client, e.g. their credentials or which service is responsible for their requests.
Listing connections
With a desired channel in place, we can start a few clients and then go straight to the listing of connections, as in the screenshot below:
By default, all connections for a given channel are listed but it is possible to filter them out by external client ID - each WebSocket identifies with a unique client ID, as assigned by the system on whose behalf the WebSocket connects. This makes it easy to find connections even if they go through a series of networks.
Each WebSocket is identified by a series of attributes, Client, Remote, Local and Connection time.
Each Client connection has a few of identifiers:
- Unique connection ID assigned by Zato, changed each time a client connects
- Client ID - unique ID assigned by the remote end, persists across connections
- Client name - similar to Client ID but there is no requirement that it be unique
Remote TCP end has two attributes:
- IP address as observed from a Zato server's perspective
- FQDN (domain name) of that IP address
Local server to which a WebSocket is connected:
- Its IP address and port number
- Server name and server process ID (PID) to which the WebSocket is attached
Connection time is by default presented in the current user's timezone but clicking it changes the format to UTC.
Checking pub/sub subscriptions
WebSockets may participate in pub/sub processes and it is possible to look up all the topics a particular connection is subscribed to. Note that subscription times may predate connection times - this will be the case if a WebSocket connects, subscribes to a topic, then disconnects and connects again. In such a case, the subscription time will be earlier than the last connection time.
Invoking WebSockets directly
It is possible to send requests straight to a WebSocket, waiting up to timeout seconds for the reply. This lets one communicate with the remote connection directly, which is of great assistance in many low-level diagnostic scenarios.
Disconnecting API clients
Each WebSocket can be disconnected separately - on the protocol level, it will send a Close event to the remote end, afterwards cleaning up all the internal resources taken up by the connection.
Summary
API integrations with WebSockets offer an alternative to REST whose greatest advantage is reduced runtime processing overhead. Zato offers built-in GUI tools to create and manage WebSockets, including searching, listing and direct communication with each WebSocket straight from a browser's window.
To learn more about how to integrate APIs with Zato, visit the [tutorial]/en/docs/3.2/tutorial/01.html) and downloads sections of the extensive [documentation]/en/docs/3.2/index.html which cover everything needed to get started with the platform.