Skip to content
This repository has been archived by the owner on Jan 31, 2024. It is now read-only.

Update (message) delivery guarantees #36

Closed
WofWca opened this issue Apr 1, 2023 · 6 comments · Fixed by #74
Closed

Update (message) delivery guarantees #36

WofWca opened this issue Apr 1, 2023 · 6 comments · Fixed by #74

Comments

@WofWca
Copy link
Contributor

WofWca commented Apr 1, 2023

This is not clear from the docs.

  • Is it guaranteed that all sent messages are delivered? In part, if you send two messages and the second one is delivered, is it guaranteed that the first one is / will be delivered?
  • If you're offline, when you send a message, is the updateListener immediately invoked or does it wait until you come online to sync with other users?
  • Is it guaranteed that every consecutive updateListener invocation will be passed a message with a higher serial than the previous one?
  • Is it guaranteed that for every user, and for every launch of the app, the messages will be passed in the same order (and that none will be skipped)?

I'm not a computer scientist, but the questions seem similar to the ones you would ask about reliable/unreliable in-order/out-of-order network protocols, and CRDTs, so perhaps we need to look up if there are any other important questions that need to be answered.

@Simon-Laux
Copy link
Collaborator

Simon-Laux commented Apr 4, 2023

If you're offline, when you send a message, is the updateListener immediately invoked or does it wait until you come online to sync with other users?

yes it should be run immediately, also you should do you actions in the listener, regardless whether you or an other user did the status update.

Is it guaranteed that every consecutive updateListener invocation will be passed a message with a higher serial than the previous one?

the serial is generated by the receiver and not synced between devices nor users, so yes.

Is it guaranteed that for every user, and for every launch of the app, the messages will be passed in the same order (and that none will be skipped)?

yes, as long as your listener callback is not buggy and you don't request messages only after a specified serial number.

at the moment webxdc has some transport layer, how we make it more reliable and if we offer some auto repairing synced state for webxdc managed by core or a standard js library (like webxdc.js, that app devs can use without bundling it) are questions for the future.

@WofWca
Copy link
Contributor Author

WofWca commented Aug 15, 2023

Is it guaranteed that for every user, and for every launch of the app, the messages will be passed in the same order (and that none will be skipped)?

yes, as long as your listener callback is not buggy and you don't request messages only after a specified serial number.

You mean that the order is the same for a single user, not that it's the same between all users? Based on:

the serial is generated by the receiver and not synced between devices nor users

@Simon-Laux
Copy link
Collaborator

You mean that the order is the same for a single user, not that it's the same between all users? Based on:

exactly, emails can get delayed or go missing so order can not be guaranteed.

@WofWca
Copy link
Contributor Author

WofWca commented Sep 21, 2023

emails can ... go missing

Doesn't this mean that apps must implement a reliability layer (acknowledgement messages, etc)?

@link2xt
Copy link
Contributor

link2xt commented Sep 28, 2023

emails can ... go missing

Doesn't this mean that apps must implement a reliability layer (acknowledgement messages, etc)?

Yes. For example, if you edit the title of the doc in editor, and this update is not actually delivered to anyone while everyone else is editing the footer, they will never notice that the title was changed by you. If you want all updates to propagate, you need to assign sequence numbers or linked IDs to all updates you send and have some way for receivers to notify you if they have some IDs missing.

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

Successfully merging a pull request may close this issue.

4 participants
@link2xt @Simon-Laux @WofWca and others