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
Nodes that offer invalid data will currently be allowed to keep doing so wasting bandwidth and cpu of the receiving node.
Any offer that has a properly encoded content key and that falls in the data radius of the receiving node will be accepted.
Data will be send and once received it will be validated. If the data fails validation, the peer currently is not punished and thus allowed to keep offering this or other invalid data.
Similary a node can provide invalid data on a FindContent. Or send no data at all or very slow until uTP transfers time out.
We should add a temporary ban list for nodes that do this.
There might also be nodes that end up in the DHT of a specific subnetwork for some reason, but don't actually support the subnetwork. Might require a temporary (per network) ban list for these to avoid trying to ping over and over a node that is not supported.
The text was updated successfully, but these errors were encountered:
WRN 2024-11-06 11:11:29.853+01:00 Offer failed due to accept request failure topics="portal_wire" error="No message data, peer might not support this talk protocol" contentKeys=@[0x00458ff92094a00fac6e393a435d58242c4971e9711adf1cd16215fc97856e4a1e] node=b7*406c26:164.92.247.243:5008
This is definitely a good candidate as reason for subnetwork specific temporary bans. As it really indicate a node that does not support a subnetwork.
In theory these should get filtered out of the subnetwork DHT, but if other clients don't do that properly or if the node does reply to ping/pongs on that subnetwork, this will not occur.
Nodes that offer invalid data will currently be allowed to keep doing so wasting bandwidth and cpu of the receiving node.
Any offer that has a properly encoded content key and that falls in the data radius of the receiving node will be accepted.
Data will be send and once received it will be validated. If the data fails validation, the peer currently is not punished and thus allowed to keep offering this or other invalid data.
Similary a node can provide invalid data on a FindContent. Or send no data at all or very slow until uTP transfers time out.
We should add a temporary ban list for nodes that do this.
There might also be nodes that end up in the DHT of a specific subnetwork for some reason, but don't actually support the subnetwork. Might require a temporary (per network) ban list for these to avoid trying to ping over and over a node that is not supported.
The text was updated successfully, but these errors were encountered: