Bitcoin Forum

Does anyone have benchmarks for websockets vs FIX protocols for exchanges?

What is the best ways to create a meaningful benchmark between the two?

Thanks

Hey jcrubino,

First make a list of the FIX protocols offered by exchanges, to my knowledge the one's offering fix are:

• Coinsetter - https://www.coinsetter.com/api
• There is one other one I can't think of right now...

Than I'd setup a number your benchmark too PING the APIs and record average latencies. I don't know anyone whom has done this yet as the FIX offerings across exchanges are pretty limited versus HTTP-esc and Websockets style protocols.

One gentalman whom is heavily involved in FIX and has an interest in Bitcoin: George Kledaras, http://www.wallstreetandtech.com/author-bio.asp?author_id=1421, see: http://www.wallstreetandtech.com/trading-technology/is-fix-protocol-use-declining/a/d-id/1252798?

Thanks
I have read this article before... I have no doubt he knows way more than I... but I do not understand the premise of Bitcoin and Bitcoin exchanges as driving a trade protocol forward if speed is the main feature unless websockets is the alternative.

Well, I am generally of the persuasion that given the current state of most Bitcoin exchange APIs, Messaging protocols, etc., it'll be a long time before there is enough genuine incentive for exchanges to offer truly 'real-time' trading protocols.

Take BTC-E which runs a Metatrader server (and regardless of what you think of MT, it's still much snappier than the majority of the BTC Exchanges out there).

Given the majority of order-flow I speculate is still retail, there is little incentive for exchanges to build out algo-oriented communications protocols when the majority of your customers use the website to enter orders.

In short, I don't see 'Bitcoin Exchanges' pushing order messaging as it relates to trading 'forward', though there are some novel approaches to settlement (blockchain) and using multi-sig liquidity verification. At the end of the day if your customer is institutional they'll demand a variety of protocols - if your customer is retail, they probably don't care that much.

well said

Btcchina, okcoin, huobi - offers a fix api also.

I am also intrested in the benchmark (FIX vs websocket latency) would appreciate any further thoughts on this subject

Is there any reason why one couldn't run FIX message traffic *over* websockets?

Disregarding the session layer for a second, a low-fidelity application of FIX over websockets could simply use the typical HTTP upgrade websockets handshake, then simply exchange message traffic formatting with FIX traditional tags and values for a particular data dictionary version.

Bringing the session tier back into the picture, it shouldn't be too difficult to devise a handshake that maintains the spirit of FIX session initiation yet simply uses websockets over tcp+ssl to communicate.

I suspect many trading venues in the crypto asset class originally launched with both REST and WebSockets support, with FIX support subsequently added as an enhancement.  One drawback is that this imposes upon the venue a need to maintain multiple, distinct versions of application semantics, the building blocks of which FIX does an excellent job of defining at very granular levels.  FIX can be intimidating to those new to it, and likely doesn't make sense to implement in 1.0 for a crypto-native market center.

As bigger players with an established legacy infrastructure onboard crypto asset classes, the demand for FIX connectivity to integrate should increase.  I think that discovering the ideal mechanism to run FIX session using websockets as the wire is beneficial, since it would save the exchange development personnel the effort of manufacturing API semantics independent of any larger recognized standard.

How to benchmark FIX vs REST ?

I just checked coinbase and their websockets only provide market data? So to have a functional bot, you not only need the market data, but also have to take some actions (send orders). This takes a REST API call as I see it. This REST call establishes another connection with takes additional time. Via FIX you can send your order via the existing socket connection, which should be a lot faster, as I see it.

So, the FIX messaging structure will take a lot more processing power (I just studied QuickFix/J so far, which is complicated enough, methinks), but you should gain more via reusing the existing socket, as I see it?

Maybe I don't understand the FIX concept not well enough yet, but otherwise a benchmark would have to get market data _and_ send orders.

How to perform such a benchmark? Set up a simulated exchange with FIX API, so you have predictable market data being send to the client?

Very good questions. So far no exchange has released benchmarks of any kind, that I'm aware of. We will be the first to do so.

FIX is not really a Internet network protocol - it is a semantic layer for financial transactions. FIX runs over TCP or other network protocols, in this case TCP over the open Internet. Websockets will definitely be much slower. Additionally WS does not provide much reliability. It makes much more sense to write custom protocols using TCP and UDP, or thin and performant layers on top of it.

FIX (see [1]) was designed around institutions such as banks and exchanges transacting between each other on Wall Street. It is fairly low level and not very sophisticated. Cryptocurrency exchanges have the benefit they don't depend on this legacy.

On the question what is the best way to benchmark Internet/Cryptocurrency exchanges: average latency under various conditions. What matters to traders is that their order or cancel arrives timely at the server. Exchanges so far don't provide much detail how they handle load, and no tools for congestion. Because the Internet is a packet switching network different paths of packets can have very high variability of performance. The assumption of packet switching is that this is acceptable. For trading it is sub-optimal.

[1] https://en.wikipedia.org/wiki/Financial_Information_eXchange

You mean 'we' like the thread posters here? If you are interested, I'm willing to contribute....

Hi. yes, we're very interested in third party contributors. With we I mean our exchange will provide performance details and measurements. We're also interested in the question how to establish benchmarks of various kinds not only performance wise, but for security etc, and for the entire industry, similar to the World Federation of Exchanges (https://en.wikipedia.org/wiki/World_Federation_of_Exchanges).

This looks really interesting..

Did anybody ever perform the benchmarks in question?