Network map versioning and events #220

New issue

Open

opened 2025-12-28 18:08:55 +00:00 by sami · 1 comment

sami commented

2025-12-28 18:08:55 +00:00

Owner

Originally created by @roman-khimov on GitHub (Dec 11, 2025).

I'm always frustrated when I see this:

Dec 11 08:46:53 metis1 neofs-node[1649231]: info        neofs-node/morph.go:78        new epoch event from FS chain        {"number": 36477}
Dec 11 08:46:53 metis1 neofs-node[1649231]: info        neofs-node/netmap.go:250        new epoch event, requesting new network map to sync SN connection caches...        {"epoch": 36477}
Dec 11 08:46:53 metis1 neofs-node[1649231]: info        neofs-node/netmap.go:261        syncing SN connection caches with the new network map...        {"epoch": 36477}
Dec 11 08:46:53 metis1 neofs-node[1649231]: info        neofs-node/netmap.go:270        finished syncing SN connection caches with the new network map        {"epoch": 36477}

We do have a new epoch, but the network map hasn't changed a bit. All of the things node does are completely irrelevant here. What's even more problematic is that all nodes do the same thing at the same time. All nodes at least come for the "new" network map which in some cases can even lead to things like

error	rpcsrv/server.go:3231	Error encountered with rpc request	{"code": -32603, "cause": "max session capacity reached", "method": "invokefunction", "params": "[49fc858bf92e2be2c145a603320f3e6949ec75a2 listNodes ]"}

which will be resolved with retries, but still it's too easy to avoid this.

Describe the solution you'd like

Add network map versioning (just a counter). Identify maps by these numbers, store them in contract. If there are no changes to the map in the new epoch --- keep the ID the same, if there are changes --- increment it and throw an event nodes can watch for.

Same thing can be useful for policer fine-tuning, a new map version can trigger it to run faster in attempt to restore proper placements.

Describe alternatives you've considered

Things work as is, but suboptimally.

Originally created by @roman-khimov on GitHub (Dec 11, 2025). ## Is your feature request related to a problem? Please describe. I'm always frustrated when I see this: ``` Dec 11 08:46:53 metis1 neofs-node[1649231]: info neofs-node/morph.go:78 new epoch event from FS chain {"number": 36477} Dec 11 08:46:53 metis1 neofs-node[1649231]: info neofs-node/netmap.go:250 new epoch event, requesting new network map to sync SN connection caches... {"epoch": 36477} Dec 11 08:46:53 metis1 neofs-node[1649231]: info neofs-node/netmap.go:261 syncing SN connection caches with the new network map... {"epoch": 36477} Dec 11 08:46:53 metis1 neofs-node[1649231]: info neofs-node/netmap.go:270 finished syncing SN connection caches with the new network map {"epoch": 36477} ``` We do have a new epoch, but the network map hasn't changed a bit. All of the things node does are completely irrelevant here. What's even more problematic is that _all_ nodes do the same thing at the same time. All nodes at least come for the "new" network map which in some cases can even lead to things like ``` error rpcsrv/server.go:3231 Error encountered with rpc request {"code": -32603, "cause": "max session capacity reached", "method": "invokefunction", "params": "[49fc858bf92e2be2c145a603320f3e6949ec75a2 listNodes ]"} ``` which will be resolved with retries, but still it's too easy to avoid this. ## Describe the solution you'd like Add network map versioning (just a counter). Identify maps by these numbers, store them in contract. If there are no changes to the map in the new epoch --- keep the ID the same, if there are changes --- increment it and throw an event nodes can watch for. Same thing can be useful for policer fine-tuning, a new map version can trigger it to run faster in attempt to restore proper placements. ## Describe alternatives you've considered Things work as is, but suboptimally.

sami added the

netmap

feature

labels

2025-12-28 18:08:55 +00:00

sami commented

2025-12-28 18:08:55 +00:00

Author

Owner

@roman-khimov commented on GitHub (Dec 11, 2025):

This shatters the concept of an epoch somewhat, btw. I guess the other primary epoch-dependent thing is billing. But that one wants astronomic time in fact.

@roman-khimov commented on GitHub (Dec 11, 2025): This shatters the concept of an epoch somewhat, btw. I guess the other primary epoch-dependent thing is billing. But that one wants astronomic time in fact.