Skip to content
This repository has been archived by the owner on Oct 13, 2023. It is now read-only.

Snapshot for orderbook updates #50

Closed
cmollen opened this issue Mar 14, 2018 · 8 comments
Closed

Snapshot for orderbook updates #50

cmollen opened this issue Mar 14, 2018 · 8 comments

Comments

@cmollen
Copy link

cmollen commented Mar 14, 2018

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
Copy link
Owner

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
Copy link
Author

cmollen commented Mar 14, 2018

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.

@cmollen cmollen closed this as completed Mar 14, 2018
@slazarov
Copy link
Owner

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
Copy link
Author

cmollen commented Mar 14, 2018

:) 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
Copy link
Owner

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

@cmollen
Copy link
Author

cmollen commented Mar 15, 2018

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
Copy link
Owner

slazarov commented Mar 15, 2018

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
Copy link
Author

cmollen commented Mar 15, 2018

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants