Page MenuHomePhorge

Make sure we always respond with the latest sync key
ClosedPublic

Authored by mollekopf on Jan 25 2024, 1:27 PM.
Tags
None
Referenced Files
Unknown Object (File)
Sun, Oct 20, 1:52 AM
Unknown Object (File)
Fri, Oct 18, 5:24 PM
Unknown Object (File)
Sep 13 2024, 8:22 AM
Unknown Object (File)
Sep 5 2024, 1:17 AM
Unknown Object (File)
Aug 31 2024, 2:36 PM
Unknown Object (File)
Aug 29 2024, 6:11 AM
Unknown Object (File)
Aug 20 2024, 4:47 AM
Unknown Object (File)
Aug 17 2024, 10:17 AM
Subscribers

Details

Summary

Previously if a client e.g. sent a modification resulting in syncKey=4,
but then sent another Sync with syncKey=3, the server would just respond
with syncKey=3 instead of 4, which in Outlooks case resulted in the
client resending the modification that lead to syncKey=4 over and over.

Diff Detail

Repository
rS syncroton
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

mollekopf created this revision.
machniak added inline comments.
lib/ext/Syncroton/Command/Sync.php
971

Let's rename _next to counterNext.

I think resending data will be needed, especially if there are server modifications. We don't know why client sends the previous SyncKey, maybe it just lost the previous response. If we don't send what has been changed we're out of sync.

We'll have to double check, but I think the only this we're not sending is the client modifications from the previous sync from the same client.

  • Client send modification with synckey=3
  • Server responds with synckey=4
  • Client sends emtpy sync with synckey=3 (instead of 4)
  • Server now responds with synckey=4, but doesn't report the modification again.

Renamed the member variable

This revision is now accepted and ready to land.Jan 26 2024, 9:32 AM