chore: consider disabling keepalive on nwaku

[jm-clius]

Background

Previously an optional keepalive mechanism was added to nwaku to use libp2p-ping protocol to keep idle connections alive. Without this mechanism connections would be closed after 5 - 10 mins if it carried no messages.

We have since seen significant increase in network traffic as well as connection management strategies in combination with discovery that may make this mechanism obsolete. Although this mechanism can still be useful in test environments, it's likely not necessary on fleet nodes any more.

We'll have to consider all the implications in more detail, but it should be possible to disable keepalive with no effect.

Acceptance criteria

• keepalive disabled on nwaku fleet nodes

cc @alrevuelta

[alrevuelta]

btw, even if we had no traffic, guess that gossipsub hearbeats and the underlying cotrol messages would keep the connection alive?

beyond this but perhaps filter is the only protocol that could be affected? so we would need a dedicated filter keepelive?

[jm-clius]

Well, I think the control messages are sparse enough with no traffic that the connections do time out. Not exactly sure why, but we observed this previously. Perhaps because GRAFTed connections carry no control messages? That said, as long as we have a proper peer connection management strategy, there should be no strong reason to keep these alive. In fact, it should be simple to test in an offline scenario.

I don't really see the need for filter keepalive in nwaku. From the filter service node's side it would attempt to recreate a connection whenever it pushes to a client if that connection no longer exists. From the client's perspective it may not be able to receive incoming connections, but it could use the new filter PING protocol to keep the connection and subscription alive.

[chair28980]

Closing per nwaku meeting Sep 12 '23