Show HN: Binance Orderbooks Consumer in C++

https://github.com/xreptoid/viperfish

by paketick • 3 years ago

42 37 3 years ago

github.com

yelnatz• 3 years ago

Windows support soon?

nazgulsenpai• 3 years ago

Is there any reason you couldn't use WSL for something like this?

gumballindie2• 3 years ago

Better yet - Linux. Why would someone want windows to snoop on their trading? Let alone the poor performance of that OS.

jeroenhd• 3 years ago

It's cmake based, you can download cmake and the other dependencies and just compile it.

Edit: actually no, the networking bits have some platform specific #ifdefs. The code looks not too difficult to rewrite into a WinHTTP based client, though.

paketick3• 3 years ago

Windows will be supported. Not sure when, but likely in a month or two.

dmaa• 3 years ago

You say realtime feed, but at the same time use the websocket feed that updates every 100ms as your source. Am I missing something?

ot1138• 3 years ago

Whew! 100ms??

Ancient history.

paketick3• 3 years ago

You are correct. When I referred to 'real-time', I meant it in the sense that it is as efficient as consuming data directly from the exchange's WebSocket because, during the consumption stage, data is directly consumed from the exchange, not an intermediate server.

Since Binance only provides 100ms diffs, there isn’t 'real-time' in the sense of receiving each atomic orderbook change. Thank you for your feedback, I changed the description.

rohith25062• 3 years ago

`bookTicker` is realtime but the caveat is you will only get bbo (best bid and ask)

p0w3n3d• 3 years ago

Why bother? The FPGAs HFTs connected directly to fiber will trade the sh*t out of you.

rohith25062• 3 years ago

In traditional finance where machines are colocated, yes. That's not the case for crypto

posnet• 3 years ago

The crypto/cloud equivalent is letting market makers connect directly to the exchange front end servers via AWS VPC peer or equivalent rather than going via the public load balancers.

shric2• 3 years ago

And even in non-crypto it's not only about who is the fastest.

dist-epoch2• 3 years ago

There are exchanges which offer that in crypto too - Deribit has colocation in Equinix LD4.

loveparade• 3 years ago

No such thing as colo for most crypto exchanges, at least not officially. But your general point still stands. This is a cute project that's likely useless for anything serious. People go to great lengths to shave a bunch of ms off these feeds.

anonymoushn2• 3 years ago

There aren't any. The fastest access you can get to Binance is in apne1 (az depends on which products you are trading). There are also a lot of systematic strategies worth automating that aren't really latency sensitive.

yieldcrv• 3 years ago

lots of programmatic strategies are not latency sensitive, most even

and the crypto market, despite its volatility, does not move that fast, it just has 24 hour trading, in comparison of 6-8 for equities, in a single day

so the 3x greater trading sessions create the eternity

nly• 3 years ago

Using doubles for crypto prices instead of fixed point seems like a disaster waiting to happen?

paketick3• 3 years ago

The orderbook class uses original strings received from the exchange as keys. However, in some places, numbers are compared with a precision of 1e-12 as long doubles. I plan to modify this to use the symbols' price step from exchangeInfo.

virtualritz• 3 years ago

Using doubles for crypto prices instead of fixed point seems like a disaster waiting to happen?

TDLR; nope.

That depends what you use the incoming data for. Bookkeeping, yeah. And that's about it.

This doesn't look like it was meant for that. Some sort of trading where you track a bunch of indicators over a day (not HFT at their timings at the moment but along those lines): you absolutely want to avoid fixed point because of the speed penalty. See also [1].

[1] https://news.ycombinator.com/item?id=15808316

bnastic• 3 years ago

Indeed. Although I don't know what precisions are required in crypto products, in traditional trading an 8 byte double is quite enough - the price submitted will have to be rounded to the instrument's precision anyway (e.g. most spot FX products are rounded to 5 decimal places).

With a caveat here, after a very quick look at the code: The price here is defined as long double, which can be different among platforms... My Mac/clang says that long double is still 8 bytes, Linux on that same arm64 machine says it's 16 bytes (and I'm not sure what that's mapped to these days - 80bit FPU instructions, or some Float128 representation)

VHRanger• 3 years ago

I think it's down the list among several dozen other issues for accurate crypto pricing on binance

dist-epoch2• 3 years ago

No. You're overthinking it.

It's not a good practice, but no disaster will happen either for this particular purpose - a trading API.

tovej• 3 years ago

How can you say that so confidently? Floating point is terrible for decimals, as any number not consisting of only 0's and 5's after the decimal point does not have a precise representation. What if you're counting ratios or differences? Those values are no longer precise. What if you're comparing those ratios or differences? That comparison cannot be trusted.

What if you have a NaN? Now all your comparisons return false and any values you calculate from the NaN will also be NaN.

There is no way you can confidently claim these issues won't show up in a production system without doing fuzzing and formal verification. Just use big integers, 64 bit integers can represent 18 quintillion (short scale) values, which if you're trading in fractions of cents should be enough of a range for the foreseeable future. 128 bit integers will always be enough.

baz00• 3 years ago

As someone who works on trading systems, this is stupid.

gpderetta• 3 years ago

That's long double with 64 bit mantissa. I think they'll be all right.

Copenjin• 3 years ago

Minor disaster with the probability of becoming something worse, you never know where these values will end up being used/stored and it's likely that somewhere else in your code some weird form of equality will start appearing at some point (value1-value2<1E-04, lol).

There are a lot of alternatives, use them.

Never use floats for prices and rates.

max_• 3 years ago

You can compute floats all you want, but crypto APIs have a finite number of decimals the accept, other wise, you get a precision error.

daveed• 3 years ago

Isn't binance going away? Feels like they're going under heavy pressure and are getting restricted everywhere.

Show HN: Binance Orderbooks Consumer in C++

Related Stories