Update 8th August, 2024

One question

Why would you expect to see shunning?

  • if you are shunned then its forever. If a node shunned you while your node was off then you will never see it.
  • and if another node didn’t shun you then you won’t see it shunning you since the node is back online

So expected behaviour.

The consequence though is a loss of overall connectivity as now you have nodes that will never talk to your nodes again, and there will be no indication.

1 Like

Actually I wonder if this is a reason for the network running poorly. People stopping and starting their nodes without the peerid/xor being renewed since its stop/starts or power off/on and causing those nodes to be shunned by long running nodes and only new nodes are talking to them.

people reseting are fine

2 Likes

On shunning, I am still hoping for clarification on what that means and how to judge node health. So what I’m actually referring to is the count of “bad node” messages appearing in the logs and displayed by vdash.

AFAIK the isn’t a state which can be called shunned. Maybe by a single other node, but collectively not.

So you could actually have a node go from ok, to shunned by almost everyone, but eventually be accepted back due to churn.

2 Likes

Can you please explain how you see the 2.

Shunning vs seen as bad in the logs.

It was clarified. The bad node messages are saying shunned and is permanent
I asked and was answered on discord.

only by new nodes though, the older ones still remember

Maybe I don’t understand the routing and close groups enough, but here is as I see it.

In my mind simple power/internet glitch or reboot causes lot of shunn which then causes:

  1. Nodes permanently “crippled” even when they are perfect citizens otherwise
  2. Unnecessary lower network resiliency as we ignore nodes we could use for recovery
  3. High global churn rate which degrades network performance

I know shun is bad actor protection, but is the permanency best solution? Imagine big, long running network and perfect node running from the start, how long will be it’s shunn-list? Will it be checking every new connection against list of 1M nodes were bad or had connection problem sometime in history?

1 Like

Since the last update, through node manager, I have had a maximum of 5 shuns. I did a one time start and stop of nodes, again I see no more than 5 shuns. Before the update I had like 50 shuns of continuous running nodes. Everything seems the be working nicely with nodes from home. Data is flowing through like an easy river, thousands of records coming and going as expected. Only thing not being caught in my net are nanos.

1 Like

The permanent is not for unintentional bad nodes but intentionally bad nodes. If its not permanent then they can just stick around and attack again.

The obvious reaction of any node if bad is to restart with new peerID and see if that fixes things.

Not good if intentionally bad, but you can do nothing about that

But for the unintentional bad then its way faster than having to wait hours till the shun times out.

It will have to be built into the launcher to do that and I see from the screen shot in news the launcher can determine if the node seems bad and could just kill the node and start a new one

2 Likes

Shunning hasn’t really been defined AFAIK so this is just how I’m using it.

A “bad node” message in the log means another node has a problem with you, but has not necessarily shunned or blacklisted you. (I may be wrong about that, but I think that was the initial implementation).

If enough other nodes “bad message” the same name node they may each decide that’s enough and blacklist it - or not - independently, there’s no formal consensus.

vdash counts received “bad node” messages. It can’t know when the node has been blacklisted or by how many others AFAIK.

As there’s no formal consensus or threshold the term shunned is nebulous, and a node that just sticks around long enough after being completely black listed could come back into the game due to churn, provided it’s behaviour has improved sufficiently.

Much of the above may be out of date or plain wrong. It’s what I’ve gleaned over time from what’s been said by the team.

EDIT: in the next release a node will be told when it is about to be blacklisted: Release rc-2024.08.1.2: chore(release): release candidate 2024.08.1.2 · maidsafe/safe_network · GitHub

2 Likes

Yeah I think we share more or less the same vague idea on what is going on. :+1:

I think it was said 3 bads is a shun, but only within a specific time frame and from that particular node.

Super hard to know whats going on.

3 Likes

Reading all of the above and trying to get a handle on whats actually going on – and failing.

Only definitive thing I can say is we need to be able to analyse the logs more effectively - and I think everyone is now tired of me saying that.

So I am off to see what can be done there.

Expect frantic pleas for help in the near future :slight_smile:

Productivity will be low however as I am in constant pain. My back was sore enough but now my sides are absolute agony. Dunno if this is related…

1 Like

I don’t remember the log message exactly but I assume it tells you which node saw you as bad and when.

So really if we determine what causes a shun we could get NTracking to count shuns not just being seen as bad.

My version currently only tracks how many times each node is seen as bad and that is pretty useless.

2 Likes

Update for @Josh

2 Likes

I saw something in git hub about that coming in the metrics so I’ll hopefully be able to add it in soon :slight_smile:

2 Likes

Shunning is just a human way of describing the bad node message. Yes I got that from the devs themselves. So in this case it is “defined”

Bad node message is the node saying I am not talking to you again. This is what the dev said

I jumped on that when the bad node message was mentioned by the dev and clarified it straight away.

Don’t listen to me but its Roland who confirmed it. And you even reacted to it, must be old age memory kicking in :stuck_out_tongue_closed_eyes:

1 Like

Yeh, my memory is terrible these days. God knows how I can still write working code etc, I thought I was past it when I came to this project but :man_shrugging:

BTW, if it isn’t documented, it isn’t defined IMO and without investigating, I can say that there is a commit in the latest release which differentiates between the bad node message and being blacklisted. It implies that previously it wasn’t being sent for blacklisting but prior to that.

I wonder if the word “shun”/“shunned” will ever get that. The dev team internally is obviously using the bad node and not the descriptive word shun.

I think though Roland was very clear that shun and bad node message are equivalent in meanings.

2 Likes

This is a critical issue that needs well documented and explained. I have brought it up

12 Likes

So glad you are back, Just take it easy ok?
One miracle before and after lunch and thats your lot…

2 Likes