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

Use time-based counter instead of stored counter for transfer ID #169

Merged
merged 1 commit into from Mar 23, 2021

Conversation

dirkmc
Copy link
Contributor

@dirkmc dirkmc commented Mar 22, 2021

Currently the data transfer ID is produced by an incrementing counter stored in the datastore.

The datastore state sometimes gets out of sync in real world clients. If the state gets wiped on the client, the counter starts from zero. However miners do not accept a transfer which has an existing client peer ID and transfer ID. So all transfers from that client will be rejected until the counter reaches the same level it was at before.

To avoid this problem, this PR changes the way that the transfer ID is generated: the ID is derived from the current time.

@dirkmc dirkmc force-pushed the feat/remove-stored-counter branch from e473792 to 1bee82b Compare March 22, 2021 16:32
impl/utils.go Outdated Show resolved Hide resolved
@dirkmc dirkmc requested a review from nonsense March 22, 2021 16:37
@dirkmc dirkmc force-pushed the feat/remove-stored-counter branch from 1bee82b to 92874c4 Compare March 22, 2021 16:57
@dirkmc dirkmc force-pushed the feat/remove-stored-counter branch from 92874c4 to 8b16747 Compare March 23, 2021 10:03
@dirkmc dirkmc changed the title Use random number instead of incrementing counter for transfer ID Use time-based counter instead of stored counter for transfer ID Mar 23, 2021
Copy link
Member

@nonsense nonsense left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, I think this is safe.

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

Successfully merging this pull request may close these issues.

None yet

2 participants