You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, SCAMPjs provides each peer with an identity supposedly unique. However, it only randomizes an integer within a range (very thin for now). Thus, there is a probability that two peers get the same identifiers and that may creates problems.
TOFIX: Maybe consider a way that the first peer gets its identifiers from a peer within the network. Each peer gets an allocating range for new peers (from bounded, or dotted version vector I think?). For instance, the first peer got the identifier 0 and an allocation range [1..100], a second peer connects to it. This peer gets 50 has UID and can allocate identifiers from 51..100. Now the first peer can allocates identifiers from 1..49 and so on. When the allocating range becomes empty, the set of identifiers is enlarged by creating a branch. For instance the first peer could allocate identifiers has [ 0 , X ] where X is the new allocating range. New peers connecting to the first peer would get unique identifiers since only this peer provides identifiers prefixed with "0".
TOTHINK: the aforementioned uids may grow quickly -> use exponential tree ?
The text was updated successfully, but these errors were encountered:
Possibly not even necessary to have unique site identifier. The important part is to stay with uniquely identified messages which is currently guaranteed by the use of site identifier and local monotonically increasing counter.
There exist lightweight mean to provides this, with high probability. For instance, hashing would provide the unique identifiers and a cache would clean the messages afterward. The cache must be large enough to know if a message has already been received before and act accordingly (for instance, stop re-broadcasting it).
Currently, SCAMPjs provides each peer with an identity supposedly unique. However, it only randomizes an integer within a range (very thin for now). Thus, there is a probability that two peers get the same identifiers and that may creates problems.
TOFIX: Maybe consider a way that the first peer gets its identifiers from a peer within the network. Each peer gets an allocating range for new peers (from bounded, or dotted version vector I think?). For instance, the first peer got the identifier 0 and an allocation range [1..100], a second peer connects to it. This peer gets 50 has UID and can allocate identifiers from 51..100. Now the first peer can allocates identifiers from 1..49 and so on. When the allocating range becomes empty, the set of identifiers is enlarged by creating a branch. For instance the first peer could allocate identifiers has [ 0 , X ] where X is the new allocating range. New peers connecting to the first peer would get unique identifiers since only this peer provides identifiers prefixed with "0".
TOTHINK: the aforementioned uids may grow quickly -> use exponential tree ?
The text was updated successfully, but these errors were encountered: