WebSocket API
The ALOR Broker trading system supports communication via the WebSocket protocol through the WebSocket API.
This communication channel is designed for high-speed asynchronous data exchange within a single session.
Interface Features
The WebSocket API is based on a stateful, bidirectional communication model. Once a connection is established, the channel remains open, which allows the server to proactively send data to the client without a prior request.
This interaction model has its advantages and disadvantages in practical use of the interface.
| Advantage | Disadvantage |
|---|---|
| A persistent connection minimizes latency by eliminating the need for repeated handshakes | Any network failure results in the loss of all active subscriptions and requires a procedure to fully restore them |
| Asynchronous and bidirectional data exchange allows the server to instantly broadcast market changes | The presence of a single message stream requires the implementation of parsing and data distribution mechanisms on the client side |
| Real-time delivery of updates eliminates the need for constant system polling | Risk of buffer overflow during high-intensity incoming message traffic, which may lead to forced session termination |
| The minimal header size in frames reduces network load compared to the classic HTTP model | Specific requirements for firewalls and proxy servers to support long-lived TCP sessions |
In addition to the features listed above, the following limitations apply to this interface:
- No more than 10 concurrent connections;
- No more than 5000 subscriptions per session;
- No more than 5000 unprocessed messages in the server buffer.
Use Cases
The WebSocket API is the right choice for tasks that require fast response times and up-to-date data. Below are several scenarios where using this protocol is appropriate:
| Appropriate | Inappropriate |
|---|---|
| Real-time retrieval of quotes, order book updates, and trade feeds | Loading heavy static reference data and complete instrument lists |
| Real-time monitoring of order statuses and portfolio changes | Retrieving historical data over long periods of time |
| High-frequency trading with strict latency requirements | Occasional account status checks in low-activity scenarios |
| Maintaining an event-driven trading algorithm | Regular retrieval of data that does not require an immediate response |
Use the HTTP API for the initial loading of reference data and historical data.
High-frequency market data should be separated from critical system notifications by distributing them across different connections.
Recommendations
To ensure stable communication and reduce the risk of being blocked, follow these guidelines:
- Use a local buffer. Implement a “receive-store-process” model to avoid server buffer overflow (limit: 5,000 messages).
- Manage the subscription lifecycle. Assign a unique
guidto each subscription for identification and unsubscribe from obsolete streams in a timely manner. - Use reconnection strategies. If a connection is lost, use
backoffandjittermechanisms to avoid a sudden surge in system load when restoring sessions. - Adhere to quantitative limits. Enforce limits on the client side for the number of open connections (up to 10) and active subscriptions (up to 5000 per connection) in accordance with system rules.
Combine all available system interfaces to solve your tasks as efficiently as possible.
Ignoring these recommendations and/or using the WebSocket API for purposes other than its intended use will result in your access to the system being blocked. For more details, see the article “Limits and Recommendations”.