What are websockets?

The backbone of the current internet is based on the HyperText Transfer Protocol, a robust protocol that allows systems on the internet to efficiently transfer, send and receive messages. However, HTTP have its limitations, namely in cases where transfer speed and bidirectional transfers are concerned. Some of this limitation is addressed on another protocol called WebSockets, in which we’re going to discuss.

The classic HTTP protocol, in essence, is about requesting and receiving messages between a client and a host server. In order to successfully transmit those requests, there are some necessary steps, such as a network handshake where the two connect with each other and acknowledge, then verify the quality of the connection. Then, some servers require further authentication for the client, such as using API keys or passwords. Only then the client can request data from the host, and the host would return the response. After the response is received, then the connection would be terminated. If there are further request, the flow would be repeated.

A simplified diagram is shown below, where a client is asking some data from a server

Why are websockets needed?

For most purposes, this protocol is sufficient. However, two glaring problems are visible. First, the Client-Host are required to establish a connection, acknowledge it, then authenticate for every request the client creates, this presents a significant time lag in communication. Second, only the client is able to make any request, and the host is only able to respond to the request. In order for the host to make request, we need another set of access points calls and structures altogether.

The two problems are solved by the Websocket Protocol. Websocket guarantees a persistently open connection between the client-server until one party closes or lost the connection and bidirectional, full duplex communication, i.e. there is no need for more than once authentication and the host is able to make requests directly to the client.

Why are they needed in an online trading platform?

Some of the more pronounced user of websockets utilise the advantages of it, some examples are chatting and video conferencing applications to stream data continuously    and to guarantee that both parties in the chat are up-to-date with any new data. Another industry that will benefit from websocket is financial exchanges, where execution speed and data transfer might mean profit or loss.

Financial exchanges usage for websocket protocol may be split into two different uses. Data broadcast and account-exchange interactions. Here we will explore both using examples from Bitwyre’s own and using other exchanges eg Binance, FTX, Huobi

Data broadcast and streaming is as simple as it sounds, to get data to end users as efficiently as possible. Due to the ever-changing and fast nature of financial markets, the more updated data users have, the more they can process it to make decisions. Websocket provides this better than standard HTTP since, once connection is established, the host can stream live data continuously and indefinitely to the clients without any reconnecting necessary and without the need to aggregate/discretize said data.

Examples of data broadcast is the subscription of live market data towards end users, such as market price of an asset, orderbook depth, latest trades, etc. As we know, these kind of data in financial markets move quickly, in magnitudes of less than milliseconds, thus, getting the most updated data is of utmost importance to end clients.

We can see the speed difference between the two frameworks as follows, in which we use the websocket and rest api to get the depth of our orderbook in the span of 300 data points

Websocket returns data at almost double the speed of REST, also with much less deviation i.e. better consistency. Note that there is an outlier at almost 6 seconds in websocket, which was the first time the websocket connected to the server since websocket anecdotally has a longer initial connection process. In real life scenario, the half-second difference between the data stream might lead to better data granularity, more resolution, faster responses,  and better decision-making

Comparison Analysis: Bitwyre vs Other Exchanges

Websocket market streams are pretty common among exchanges, such as Bitwyre’s own, FTX, Binance. Bitwyre’s stream, however, is superior in two ways. Currently, our market stream is connected directly to our live matching engine and in-memory storage, ensuring whatever is given in the stream latest.

We also note that most other exchanges are limited by RFC standard, in which a given data payload is limited to a 126 bytes without pagination or fragmentation[1], thus limiting the information sent, in which case most exchanges are only able to send a partial snapshot of orderbook. We are currently experimenting with websocket fragmentation and/or pagination to support full orderbook data.

This discrepancy is due to a mostly-not-enforced standard in RFC stating that a websocket message may be over 126 bytes long, but only if the host gives acknowledgement to the client first (further reading: Continuation Frame on RFC-6455).

Another advantage that Bitwyre websocket has is its current account interaction API integration in websocket. It means that users can create/cancel orders, get order status, or check their balance via websocket, which we saw earlier is noticeably faster. A high-frequency trader would surely make use of this feature since they can maintain a connection to the exchange and create (or cancel) an order of less than a millisecond using websocket.

Benchmarks

Another example is below, where we create 250 exact same order through websocket and REST api and calculate the time to response in milliseconds:

It seems that, even though Websocket is significantly faster, almost by 4x that of REST, the deployment itself is still quite unstable, given the big spread and long tail. However, as the majority of the Create order returns are faster than REST, we can be sure as a proof of concept that high-frequency traders may shave upto 200 milliseconds in creating order.

As of now, there are no major exchanges that are implementing such an in depth websocket solution for orders and accounts, e.g. creating and cancelling orders. We saw that using websockets may reduce round-trip-time of messages of up to half a second and give user a more thorough picture of the market. This comparative advantage and efficiency of websocket will be beneficial to customers