[binance] Possible to reduce the depth for the order book stream?
Opened this issue · 10 comments
Hi I wonder if I can set parameters like depth for order book streaming for Binance. Thanks in advance!
Hello @andrewlin0410 . In order to do that the BinanceStreaming implementation must support it or you can add it yourself.
@andrewlin0410 the order book is 1000 prices deep at the moment I think. Do you want it smaller or larger?
There is no way to limit the size of the order book on the Binance websocket API (I'm not sure that it would even be possible for them to add the feature due to the way the websocket updates work). It's not really an xchange-stream issue.
If you need a limited order book, I suggest that you do so after the fact in your application code: add a map call on the observable chain, filtering down the size of the book before it hits your code. You can do this efficiently by creating a new OrderBook object populated by calling subList on the ask and bid sides of the incoming object. That just gives you a "view" over the larger underlying list rather than creating a whole new list,so it's super fast.
Oh, just as a warning though: the above is only safe if your observable chain is single-threaded.
Hm, managing dropping orders off the end of a differential stream when you're not getting the full book sounds "hard". You notice that they still suggest fetching the entire book (1000 depth) for the initial snapshot.
It'd need a lot of testing, which means someone needs to submit a PR who needs the problem solved.
I don't yet understand the reason why you need this. Do you need to limit the bandwidth? Why is it not good enough just to strip off the orders you don't need afterwards?
It would be useful to limit the initial snapshot from rest api. When you subscribe to many orderbooks, you'll hit rest api rate limit. Smaller orderbook snapshots allow you to make more calls. https://github.com/binance-exchange/binance-official-api-docs/blob/master/rest-api.md#order-book
Assuming that you have a clever enough rate limiter plugged into Events.BEFORE_API_CALL_HANDLER, yes, that makes sense. A good enough reason :)
It's an easy PR in theory, if someone wants to do it. I have a feeling that it's slightly trickier than it sounds though because of the need to manage the bottom of the order book as orders move on/off.