slazarov / python-bittrex-websocket

Python websocket for Bittrex (non async).
http://python-bittrex-websocket-docs.readthedocs.io/en/latest/index.html
MIT License
103 stars 38 forks source link

Snapshot for orderbook updates #50

Closed cmollen closed 6 years ago

cmollen commented 6 years ago

First, thanks for sharing @slazarov.

When subscribing to orderbook updates with subscribe_to_orderbook_update(), there is no snapshot syncing performed. A reasonable behaviour would be that the first update includes all levels.

I have hacked around this (at the expense of subscribe_to_orderbook()), but wouldn't mind contributing with a pull request with a more sustainable solution. Currently, the snapshot is quite heavily tied in with SUB_TYPE_ORDERBOOK, even though the overlap between the two subscriptions types seem to be quite large. How do you feel about consolidating the two types and having a variable (e.g. self.tickers.list[ticker][SUB_TYPE_ORDERBOOK]['IsDifferential']) indicate if only changed levels should be passed to the callback function?

On a sidenote, I can't figure out where in the code the client tells Bittrex which tickers are of interest. Do they simply publish updates for all tickers, leaving the client to filter out tickers of no interest?

slazarov commented 6 years ago

Hi @cmollen and welcome! Subscribe_to_orderbook_update() gives you only nounces and Its intended to do so. It’s used in the case when users have their own syncing mechanism, I.e through api request.

With regards to your last paragraph, this only applies when you subscribe to market updates, if you subscribe to the order book or executed trades, then the specific ticker is invoked. I’m on the phone so I hope this is as clear as possible.

cmollen commented 6 years ago

Thanks for the quick reply, all clear! I would assume that my use case is more common (wanting to capture and store the orderbook for future recreation, without wasting space on levels that haven't changed), but the change was minimal so I will just keep my own branch then.

slazarov commented 6 years ago

If you want to keep a live orderbook you should use subscribe_to_orderbook. With respect to the wasting space on levels, I don’t completely understand what you mean :).

cmollen commented 6 years ago

:) I don't want to keep a live orderbook, I want to store the orderbook to disk and be able to recreate it at a later time for analysis and backtesting. If I store every update passed to the on_orderbook() callback to disk, I will be wasting disk space as it passes all levels of the orderbook, and not just the levels that have been updated. So if I subscribe to 50 levels and only one is updated, I still need to save 50 levels, or check every single update to see which levels have changed.

slazarov commented 6 years ago

With subscribe_to_orderbook_update you will only get the nounces, this is exactly what you need.

cmollen commented 6 years ago

As stated in the first post, the only thing lacking with subscribe_to_orderbook_update is that it doesn't have the option to return the full state in the first update. Otherwise, it is impossible to recreate the full orderbook state. And seeing as the snapshot sync is already implemented for SUB_TYPE_ORDERBOOK, it seems like a waste to re-implement it on the outside.

slazarov commented 6 years ago

I agree that the option of requesting a full order book snapshot to be implemented, but don’t agree that it should be part of the update method. Although in your case it applies, it should be made general. I could implement it as a new method.

cmollen commented 6 years ago

That would be much appreciated. If you want to keep the number of callback methods down, one suggestion for making it more general would be to augment each level of the snapshot with a Type: 0 on the first call to on_orderbook_update. Then the format and the semantics would be the same for the snapshot and the subsequent updates.