They will be returned to pool when disconnected anyway. On a smaller network
this can make a difference because there are not a lot of addresses in the
pool usually.
Signed-off-by: Roman Khimov <roman@nspcc.ru>
It's impossible to maintain a 4K line. I'm not even sure new table works good
enough, but at least it's per-hardfork.
Signed-off-by: Roman Khimov <roman@nspcc.ru>
Function doesn't make much sense here. The change is rather trivial and this
is not expected to be used by external code, so no deprecation.
Signed-off-by: Roman Khimov <roman@nspcc.ru>
Differentiate released and stable ones from test-only not-yet-ready and such.
Enabled only stable ones by default to avoid surprises in private networks
when some beta hardfork is made available with some node release.
Fixes#3719.
Signed-off-by: Roman Khimov <roman@nspcc.ru>
It's not supposed to happen, but if blockfetcher goes wild and calls this
twice it can ruin the system, so better safe than sorry.
Signed-off-by: Roman Khimov <roman@nspcc.ru>
blockFetcherFin is closed by the block fetcher, so it will forever return
something in this loop making it an infinite loop, creating useless load
and affecting normal node operation.
Signed-off-by: Roman Khimov <roman@nspcc.ru>
Consider 10-node network. FanOut is 6 for it. optimalN is 12. But it's a
10-node network, you can't have more than 9 peers there. So adjust the formula
for netSize-1.
Signed-off-by: Roman Khimov <roman@nspcc.ru>
We can have _a lot_ of these in the log, but the only reason they happen is
because we're trying to interpret length before checking for reader error,
CMDVersion is just 0.
Signed-off-by: Roman Khimov <roman@nspcc.ru>
Dealing is fast, we don't need 10 minutes to check that connection can
(or can't) be established. Improve documentation along the way.
Close#3721.
Signed-off-by: Anna Shaleva <shaleva.ann@nspcc.ru>
Otherwise all hardforks enabled by default from genesis which leads to
errors like this if we introduce new hardfork:
```
Dec 04 02:46:46 titan1 neofs-node[157390]: warn client/multi.go:43 could not establish connection to RPC node {"endpoint": "wss://rpc.morph.t5.fs.neo.org/ws", "error": "WS client initialization: failed to get network magic: unexpected hardfork: Echidna"}
```
Signed-off-by: Anna Shaleva <shaleva.ann@nspcc.ru>
Fix the following Docker image build warning that stops privnet image build:
```
1 warning found (use docker --debug to expand):
- FromAsCasing: 'as' and 'FROM' keywords' casing do not match (line 3)
```
Signed-off-by: Anna Shaleva <shaleva.ann@nspcc.ru>
Previously, the `blockQueuer` routine, which enqueues blocks into
`bQueue`, could be blocked on enqueing newer blocks if older blocks
downloading is delayed by NeoFS.
The `blocksCh` channel, acting as a queue ordered by download speed,
conflicted with the BQueue requirement for strict sequential enqueuing
(expecting an exact range of blocks), resulting in a deadlock that
stalled the process.
Before with default config settings:
```
2024-11-27T17:12:19.348+0300 INFO persisted to disk {"blocks":
0, "keys": 116, "headerHeight": 0, "blockHeight": 0, "took": "15
.509083ms"}
2024-11-27T17:19:39.574+0300 INFO persisted to disk {"blocks":
16, "keys": 11107, "headerHeight": 216768, "blockHeight": 216768,
"took": "62.762041ms"}
```
Average block persistence speed: 492.40 block/s
Average blocks number for each persist log: 584.28
After:
```
2024-11-27T17:29:03.362+0300 INFO persisted to disk {"blocks":
0, "keys": 116, "headerHeight": 0, "blockHeight": 0, "took": "19
.485084ms"}
2024-11-27T17:34:58.527+0300 INFO persisted to disk {"blocks":
16, "keys": 11109, "headerHeight": 216770, "blockHeight": 216769,
"took": "52.43925ms"}
```
Average block persistence speed: 610.33 block/s
Average blocks number for each persist log: 752.61
Close#3699
Signed-off-by: Ekaterina Pavlova <ekt@morphbits.io>
