fluffy poke doesn't work?

[KolbyML]

I read conf.nim and it looks like poke is enabled by default

When I switched glados from trin with poke enabled to fluffy with poke enabled the graph went flat I am assuming this means it isn't working?

Glados is supposed to have poke off (so trin having it on was a bug), I thought I would make an issue because my discord messages will probably get lost.

I am thinking about making Portal Hive tests for poke

[kdeme]

Fluffy does have poke enabled by default. It can be turned of at runtime with cli flag --disable-poke, which is a hidden flag.

Tests for poke is a gap in our CI. It definitely used to work (as I tested it in the network) and not that much has change in the code. I will add a CI test to verify this.

Now, I'm not sure what your graph is supposed to show. It shows Inbound streams. That would mean streams where the Glados portal node did not initiate the connection (send uTP SYN), correct?

Because for poke functionality, the node will send extra Offer requests, which mean outgoing connections iirc. Are we sure we are looking at the right graph?

[KolbyML]

The graph we are looking at is active uTP connections Trin nodes have on the network
Since it went to 0 that means both the bridges aren’t working and glados isn’t poking
The flat lines are bugs

When I re-enabled trin (which doesn't have poke disabled made a PR for that). The uTP connections started again on the network
glados (trin on left and right, fluffy in middle)

I am going to run glados with trin poke disabled rn and see what happens
Our network running glados with trin poke enabled on the left and poke disabled on the right

So yeah given that glados +trin disabled poke looks like glados + fluffy poke enabled. I assume fluffy's poke isn't working

[kdeme]

@KolbyML
ok, I noticed only now that these are the metrics for the rest of the Trin fleet, not the Glados trin/fluffy node.

There is definitely a huge difference between Fluffy and Trin. This made me do a quick test with a local fluffy node.
It is indeed true that not to many pokes are occurring on a freshly started node, but they do occasionally occur.

This is because of this:

nimbus-eth1/fluffy/network/wire/portal_protocol.nim

Line 1088 in edba847

if maybeRadius.isSome() and

Basically, when a node that we contacted does not have the data, we want to first check its Radius before offering that data when we received it from some other node. However, we do not always have its radius (especially not for freshly started nodes) as we might not have pinged it yet.
This is a more conservative approach I guess, as one could activity try to ping it at that moment, but poke is already making the local node do more work because another node does not have to data. To add perhaps an additional request is a step to far...?

It does seem like Trin nodes gets a lot offers, but perhaps it is just due to the amount of requests from glados (and perhaps some addtional offers get re-gossiped).

[KolbyML]

I ran fluffy for almost an hour on glados in that time 3 census's and hundreds of audits were done. Non of the nodes should have been freshly started.

Trin only pokes node's it knows the radius of/in the its routing table as well

If the node isn't in our routing table we continue.

[KolbyML]

The graph's show active uTP transfers not offer requests. This implys an offer request was sent and accepted. Trin had poke on and the graph shows it was working. With how fluffy's poke was explained it is identical to Trins. I didn't run fluffy for 1 second so if poke was on and glados was running fluffy should have been poking.

^Take this graph

^ This is me running glados using trin with poke enabled

^ This is me running glados using fluffy with poke enabled for almost an hour. There are no freshly started nodes. Our bridges are broken. So what we should see is uTP requests happening from fluffy poking nodes with content.

[KolbyML]

We don't actively ping nodes so we can poke as well is what I am saying. We only poke nodes if we already have them in our kbuckets. Like it is stated fluffy does.

[kdeme]

ok thanks, then perhaps our radius cache / pinging system is bugged or working to slow. I'm not sure, I did test it only for about 5 minutes and noticed some pokes being triggered. So the poke part of the system definitely works. But I notice now also a lot of nodes that would not get poked, so the cache hits seem (and remain??) very low.
I'll test better and for longer period tomorrow.

[KolbyML]

All good and no rush. I don't think poke not working is a critical bug. But I do think I should get around to writing some portal-hive tests for it. So no rush if you guys have higher priority bugs or features focus on that first.