-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Seednode optimizations #2501
Seednode optimizations #2501
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK EDIT: Did not see it was a draft...
Ah sorry just saw it is in draft.... So the ACk is for current state ;-) |
8223148
to
27dd8c2
Compare
had the jhgcy2won7xnslrb.onion seed node running with this change since 2019-03-28 09:54 UTC. No issues showed up. yet. The issue has been that, at times, data reached the seed nodes later than an active client. So whenever the client requested data from the seed node, it happened that the seed node delivered data which the client already removed due to a remove-message. As of now, we keep a (limited) history of messages (i.e. their hashes) we already removed and check if we already removed a message we get. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we cannot do that. If the user removes and offer and then enables it again it would not be added until the 500 items get cleared out.
Have you found out why the seed node gets delayed some messages? Might be overall too heavy load of seed or that some ddos protection causes that?
Well, I thought that removing and offer and republishing an offer results in a fresh hash... ad delayed messages: not only seed nodes are affected. the issue arises whenever one node (which gets asked for UpdateData) has not yet received a remove command but the the asking node has. A few ms are enough to cause the issue. Has nothing to do with heavy load or any DoS protection - just plain P2P network latency. If there is no fresh hash for a fresh message, then we have these options:
|
8a07e10
to
956931d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Requires another review. Previous ACK was a mistake.
956931d
to
06d2186
Compare
I just saw that this PR is still open so I
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
utACK
systemd support has been added in bisq-network/bisq#2501
No description provided.