-
Notifications
You must be signed in to change notification settings - Fork 88
to many SUBSCRIBE messages #204
Comments
Workaround: Only the three default opcodes are implemented at the moment. Remove all other opcodes as workaround.
|
@littleskunk I can't reproduce this with my config, can you share yours?
|
|
Looks like the SUBSCRIBE messages are triggered by incoming received messages.
That would mean my workaround is not correct. @matanbr can you stop your node for 10 minutes. Everyone should get timeouts and remove your node from the shortlist. Than start your node again and a new logfile for me please. |
@bookchin confirmed with my own config. I restarted my node very quick. While I am sending my FIND_NODE to get a connection every incoming message will trigger SUBSCRIBE messages. 58 SUBSCRIBE messages Second test: Stoped my node for a few minutes and start again. This time everything as expected. 5 SUBSCRIBE messages. |
Okay I think I tracked it down in kad-quasar. Basically, what happens when you receive a publish message, if you aren't subscribed to it then you relay it to your neighbors who are interested. In order to determine which neighbors are interested you request their bloom filters by sending a subscribe message to them before relaying the publication. This would explain why the quick restart yielded the error and the other did not. A quick restart won't cause nodes to drop you, so when you start back up, you are receiving publications from the network before you have had a chance to subscribe to them, thus causing the mass relay. Waiting a few minutes may cause nodes to drop you and a later restart will be much cleaner giving you time to subscribe to the configured opcodes and preventing the blind subscribe/relay loop. I'm not sure if I'd consider this a bug - it is by design after all. But it does pose an issue in these cases. Especially if you have say 20 opcodes and the subscriptions are throttled by 3 seconds. It would take an entire minute for your node to finish the subscriptions and in that time you are likely to receive publications that you are not yet subscribed to. I'm going to label this one discussion as well, so we can figure out the best way to approach this. The subscribe/relay logic is important for efficient publication propagation, but at high volume can cause these types of problems. Will continue to give it some thought. |
At the end his system clock was out of sync. That was the reason he was not able to connect. |
Duplicate #257 |
Package Versions
Replace the values below using the output from
npm list storj
.Replace the values below using the output from
node --version
.Expected Behavior
Please describe the program's expected behavior. Include an example of your
usage code in the back ticks below if applicable.
I would expect 3 second delay beween each SUBSCRIBE message.
Actual Behavior
Please describe the program's actual behavior. Please include any stack traces
or log output in the back ticks below.
The node is sending to many SUBSCRIBE messages at the same time. At the end all messages timed out and the node is not able to connect to the network. Lets go on with the next seed and the same problem. Here is an example:
cat logfile | grep '24.23.171.239'
Steps to Reproduce
Please include the steps the reproduce the issue, numbered below. Include as
much detail as possible.
The text was updated successfully, but these errors were encountered: