In the SPOT depth WS API, each new message has several updates. The first update ID of a message is “U” field and the last update ID is “u”. field Each new message has to have its U equal to last message u + 1. This makes sense because, otherwise, an update occurred in between and we didn’t catch it : the order book integrity is compromised.
The Future depth WS API is slightly different. The documentation introduce another field “pu” which corresponds to “Final update Id in last stream(ie u in last stream)”. What I understand is : 'Final update ID of the last “message” sent over this stream (correct me if I’m wrong).
What I don’t understand in this API is that, having tried it, many updates occured between last message and new message because new message ‘U’ is not equal to ‘u’ + 1, but ‘u’ + something > 1.
The documentation says that I only need to ensure that new message ‘pu’ equals to last message ‘u’. Then the question is : why don’t we need to verify, like in SPOT api, that new message U = last message u + 1? What is the purpose of this “pu” ? How to keep order book integrity while it seems that many updates occur between 2 consecutive messages?
I’m not sure why this is a problem. As soon as you know the pu = u from last message, the client is not missing any message. The order book received is integrity.
There is a problem because although the new message ‘pu’ is equal to last message ‘u’, the new message ‘U’ is not equal to last message ‘u’ + 1, which means literally that the new message first update ID is not following directly the last event last update ID, which means that there are event that occurred between new message and last message that we didn’t catch.
I have just run an example, I took for example depth stream API of ETH/USDT USDSM future:
1st message :
U = 2281384470168
u = 2281384477006
2nd message:
U = 2281384477029
u = 2281384484522
This means that all update between 2281384477006 and 2281384477029 (23 updates) have not been caught, leading to order book integrity being compromised.
Could you please kindly provide explanation about where are these updates and why there are not sent through the WebSocket API ?
(This issue does not occur in SPOT api where all new message first update ID are always equal to last message last update ID + 1)