Does meteor or DDP provide any level of delivery guarantee?
Is there a possibility that in a collection containing 100 documents, 1 document is not received.
1 Like
Very interesting question!
Have never seen it happen, also not when running hundreds of tests daily. I think you don’t only need to look at DDP but also minimongo and mergebox which together make the stack.
I think it works because it’s a stream of data. If that stream gets broken that will raise an error and a new connection. Which then starts over again with a new subscription. I cannot find a real check but I think it’s fixed that way on a lower level.
Did you encounter the issue?
This doesn’t happen unless there is some kind of disruption - since we’re using websockets, messages usually all arrive in the right order.
So I don’t know if this counts as a “guarantee”, but that’s certainly how it’s intended to work.
1 Like
Thanks guys, I kept looking for information on DDP rather than web sockets.
From what I understand, websockets are based on TCP which ensures that lost packets will be resent and packets will be reordered by the client.
Also it seems that Websocket does not pre-define the number of fragments which make up a message. This implies that it is up to the client to put the fragments together and determine where the end of a message is, suggesting that they need to be processed in order because it would be difficult (not impossible but pretty wasteful) to know if 1 message ends and a new one starts in a dropped message.
E.g.
Fragment 1, Fragment 2, Fragment 4
It isn’t clear if Fragment 4 is the end of the sequence
Or if Fragment 3 ends Message 1, and Fragment 4 ends message 2
1 Like
I haven’t had it happen although it was a concern recently as one of my publications wasn’t reaching my clients all the time.
It is clearly a programming error but it is difficult to find