How do I ensure autonat always has ability to accept incoming probe?

[nazar-pc]

This might actually be a feature request in case this is not possible, namely to "reserve" incoming connection for a particular PeerId to ensure we don't expire good external addresses just because probe fails due to incoming connection limits.

[thomaseizinger]

Are you talking about libp2p-connection-limits? That one currently doesn't have a feature to allow a certain peer to exceed the limits. That could be added but it would be good first have that usecase proven.

You could fork libp2p-connection-limits and add an "allow-list" of peers for whom the limits are not enforced. It is somewhat of a double edged sword though.

Perhaps it would be better to consider your libp2p-connection-limits the hard-limit and build a soft-limit into your application to actively attempt keeping connections under that limit? For example, I think Lighthouse (Eth2 client) targets 100 connections. If you set the hard-limit to 110, and try to actively close connections once you reach > 100, you should always have space for a few AutoNAT dial-backs.

[nazar-pc]

Yes, I was talking about libp2p-connection-limits.

Allow-list could actually work, I'll just need to intercept when autonat is about to send a probe and add corresponding peer I expect to hear from into that allow-list and remove fro it once probe has finished. So that list would be dynamically controlled by an app. Do you think this is a good enough use case?

[thomaseizinger]

Adding a peer to the allow list is not going to help if libp2p-connection-limits blocks the connection because you've e.g. reached 10/10 allowed inbound connections.

You would need to patch libp2p-connection-limits to have a separate list that disables the check temporarily. But then again, I think that is somewhat of a hack. I think you'd be better served by keeping libp2p-connection-limits as is and instead target a lower, overall connection count.

In other words, actively close connections once you start hitting a certain soft-limit.

[nazar-pc]

For now I have created this wrapper: https://github.com/subspace/subspace/blob/76aaa2fdc40ddd153c350997aafe879825199192/crates/subspace-networking/src/protocols/subspace_connection_limits.rs

There was outgoing allow list initially there, but we didn't need it and removed. Let me know if something like that is welcome upstream and I can create a PR.

[thomaseizinger]

Looks great! I am open to hear how it is working for you down the line. If it ends up proving itself, we can upstream it to here maybe. At the moment, I am not yet entirely convinced that adding the ability of making exceptions is a good idea.