Open sniperem opened 4 years ago
thank for your issue, this situation happened, because the first of order book is full message which be get with async, as your says, the network is slow. so we just the client should use rest api for get full order book, our clients(web, app, sdk) has handle this situation. thank you again, we will upgrade the doc for this.
I don't think you should blame this on the slow connection, even a fast connection may delay and jitter, the key is timing and sequence.
And you know what, even I subscribe order book updates first, then get a full orderbook, sometimes there is also a gap between them
yeah, maybe, the full message which get from other server, if sync by force, not a good idea, so we suggest clients should do some handles by 'ver', if increment's 'ver' not the next of full's ver, then should resubscribe. most situation, the increment's ver is greater than the full's ver, thank you for your response.
This exchange is running for nearly a year, but can't provide this fundamental data correctly! No wonder I saw price of ask 1 is less than bid 1 on App frequently. I've developed binance/gate/kucoin/bitmax/bitmex/etc API clients, none of them has such an issue even I slow down the network speed on purpose
thank you for your issue,we will fix it.
Hope you guys fix it ASAP, it really hurts as I must call REST API to verify the order book.
We also have this problem.. any fix is planned soon?
Is it possible to update your example code and make sure that the order book is stable and functional:
Like this, it will be easier to review our code from your example.
When I subscribe order book of BTC-USDT, the replies are as follow (timestamp is added by me):
The problem is some updates are missing!! The snapshot is Ver 60688084, but the first update is Ver 60688087. You can reproduce this easily in a slow network connection(for example, 3G). you guys didn't handle the timing correctly.