Duplication of sync clients

[Дмитрий]

Hello.

The problem: new sync client is created each time when the synchronization is turned on in Browser.

Steps to reproduce:

1. Create new account

2. Enable synchronization for it

3. Go to browser://sync-internals/ make sure that there is only one device in "Sync Node Browser/device_info".

4. Disable the synchronization

5. Enable sync to the same account

6. Go to browser://sync-internals/ - there will be already two devices in "Sync Node Browser/device_info"

This is because the client identifies itself by GUID, which is generated anew each time the database is created (GenerateCacheGUID in DirectoryBackingStore::CreateTables method).

The most correct would be to use the unique device ID, which would never be changed. However, it is almost impossible to get such an ID, so more or less acceptable solution would be to generate cache_guid once and remember it in the preferences - this guarantees that clients will not duplicating until the preferences will not be wiped.

We made this change in our fork of Chromium and it works. But it seems that identifier stored in the settings is enough, and the identifier stored in the database is redundant.

Does it make sense in this case to store the cache_guid in the DB? For what purpose the cache_guid is generated randomly in all implementations/instances of DirectoryBackingStore now?

[Nicolas Zea]

This was a deliberate decision on our part. The user disconnecting from Google is assumed to mean that they want Google to forget about this device, from a Sync perspective. As such reconnecting an old vs connecting a new device are treated the same. There are too few cases where a user is expected to disconnect and then reconnect their device, so we don't try to optimize for it.

That said, if you prefer to not follow that model in your fork, chances are moving the cache guid to the preferences file would probably work in most cases. The only thing you might need to be careful about is that the client item id (with which new locally created items get assigned) will be reset since it lives in the sync db, which gets deleted on signout. This might violate the assumption that all items created by a client have a unique item id, which can have some impact, particularly for bookmarks.

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

[Дмитрий]

Thank you for the explanation. I think we'll return to the existing Chromium model in our fork.

суббота, 21 февраля 2015 г., 1:39:46 UTC+3 пользователь Nicolas Zea написал: