Open ian-p-johnson opened 3 years ago
I have checked that i am removing levels when the size is zero - there is simply no reference to the price level on a "sticking" price
My only other thought is that the updates are an offset - ie an amount to ADD or REMOVE at a level - but that would require and add or remove operation whereas the API seems to imply it is an UPDATE to the price at that level, for that side - with 0 removing REMOVE the price level entirely
I am seeing offsets out of order - by a few points, but honouring or disregarding those offsets does not help - if i was to disregard i would likely accept an earlier update with size=0 as a sparse order book is safer than an orderbook with stale prices
Copious examples available on request ..
did you manage to get the orderbook state going?
I am having problems maintaining a coherent orderbook on the V3 socket API.
I have tried filtering updates using the "offsets" field and disregarding the "offsets" field. I can maintain a good book for about 3-10 seconds then either a bid or ask price will get "stuck" - I have traced through the Websocket updates and confirmed that the message stream does NOT contain any updates (or removals) for the prices[s] that get stuck
This happens on EVERY attempt i have made, not just occasionally. There looks to be relevant activity at where the top of book seems to be moving but unless i implement a "cancel on overlap" mechanism the book will always end up overlapping
Is there an implied "cancel on overlap" assumption ? (e.g. where all asks are removed when a bid is higher .. and vice versa) - if so then the official GUI shows "backwardation" of proces (overlap) by 1 or 2 spread sometimes so i require guidance . If that is not the problem then why am i losing updates
I can provide examples easily if you require tham