ipni / cassette Goto Github PK

Add an option to run in a mode where we don't fall back to the want block mode? that seems potentially expensive and if most nodes end up supporting wantHave we should be able to at least experiment with not supporting the fallback

Originally posted by @willscott in #1 (comment)

Caused by receiver hook registry after configuring receiver to use buffered channel mailbox:

Investigate the following panic:

panic: send on closed channel
goroutine 179 [running]:
github.com/ipni/cassette.(*Cassette).Find.func1.1({0xc002475380, 0x26})
/go/src/cassette/cassette.go:97 +0x236
github.com/ipni/cassette.newReceiver.func1()
/go/src/cassette/receiver.go:69 +0x4c7
created by github.com/ipni/cassette.newReceiver
/go/src/cassette/receiver.go:44

At what point do we not need this anymore?

we should have an overall metric for the amount of lookups where cassette is able to contribute new information, and set a threshold at which it's not needed.

@TorfinnOlsen maybe is best to identify this, but I'd start with something like 0.5% of overall request impact, confirm with rhea / other stakeholders.

Originally posted by @willscott:

I suspect one thing we may want is batching:
we collect the stream of inbound mh queries, and send out wantHave's to peers every 100 or every 100ms or some other batching period, rather than writing a new message for each request

Add metrics that aid judge the health of content discovery mechanism offered by Cassette, namely:

• Bitswap message send errors
• Provider count found per request
• Batch sizes being sent
• In-flight requests

Also, expose pprof metrics to check goroutine count.

while reciprocal peering is better then non-reciprocal we still need (maybe you even have already) logic for reattempting connections to peering peers (I can link you to what is done in kubo, but it's nothing super special) since network hiccups or other issues could cause disconnections as well.

the kubo logic lives in https://github.com/ipfs/kubo/tree/master/peering

When peered nodes churn and/or a node is too unstable during broadcast it should eventually be excluded from the broadcast list.

Broadcast recipients that are offline for longer than some threshold should be removed entirely from the broadcast list.

When cassette is deployed as a fleet of replicas, add functionality for them to gossip about the participants they discover and learn from each other, so that when lookups are load-balanced all replicas are performant.

It would be good to add a long cache for found records here - should reduce the need for repeat calls and provide some resilience against flakiness

Get the peer ID of prod cassette onto https://docs.ipfs.tech/how-to/peering-with-content-providers/ so others can peer with us.

we should have some way to see the peers ranked by how many lookups they're contributing through cassette

This way we can have a triaged list of who to track down and convince to announce to DHT / IPNI