Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unique peer identifier #7

Open
Chat-Wane opened this issue Nov 24, 2014 · 1 comment
Open

Unique peer identifier #7

Chat-Wane opened this issue Nov 24, 2014 · 1 comment

Comments

@Chat-Wane
Copy link
Owner

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 ?

@Chat-Wane
Copy link
Owner Author

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).

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

No branches or pull requests

1 participant