Zato-based WebSockets are a great choice for high-performance API integrations. 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 web-admin?

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 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 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, afterward cleaning up all the internal resources taken up by the connection.