transactions ids should be 32 bits or less

[Lucio Torre]

If we have two replicas with the same replica id that create changes and by chance the two replicas ids they generate are the same, some stuff wont get synced. But on the next sync this will be resolved with high probability.

We can then reduce the size of the id a lot.

[Lucio Torre (lucio.torre)]

we cant do this. if peers A and B get a txid conflict, then one of them will have data that they did not push, and if they write next, they never get asked for those records.

[John A Meinel (jameinel)]

I don't think this is invalid. Specifically, if we ever detect a txid conflict, we fall back to requiring a full sync.

I guess your point is:

A copied to B
A syncs with C
B syncs with C (no changes detected)
A adds data, syncs with C
B adds data (gets txid conflict) syncs with C, doesn't see the conflict at rev X.
C now has B's txid, but not all of B's data. It has all of A's data.
A adds data
A syncs with C, and sees the txid conflict.
A resets its replica_uid, and starts a full sync with a new uid.
B adds data and syncs with C, but does not detect there is a conflict ever again since it is now the 'owner' of that replica uid.

One option, if we ever detect a txid conflict, we set that replica_uid as 'known bad' and all future syncs from that replica_uid are aborted and told to reset to a full sync before progressing.

That lets us use the smaller txids, and saves a fair amount of bandwidth on send/receive, and a good amount of stored data.

[John A Meinel (jameinel)]

Changing this to low. It would require polluting a replica_uid on a conflict, but that would enable this to be useful.

[Lucio Torre (lucio.torre)]

So we would need an extra step in the conversation, where the clients just calls the server to inform of a txid conflict.

If this can be added later, we can then shorten the txids, as they should be an opaque list of bytes, we can decide how long we want it to be and change that with time.