Skip to content

Correct help messages' default number of daemon out peers#10302

Open
S5NC wants to merge 1 commit intomonero-project:masterfrom
S5NC:help-message-default-peer-count-squashed
Open

Correct help messages' default number of daemon out peers#10302
S5NC wants to merge 1 commit intomonero-project:masterfrom
S5NC:help-message-default-peer-count-squashed

Conversation

@S5NC
Copy link

@S5NC S5NC commented Feb 4, 2026

On daemon initialization the number is of out peers is set to 12 when the --out-peers option is not specified, or specified as -1 by running monerod --out-peers -1.

This implies the default is 12, not unlimited, which is what -1 means in other cases. For example, sending out_peers -1 in the daemon console sets the number of out peers to unlimited.

Another set of limits are rate limits. Like the number of peers, it isn't possible to set these to unlimited with options, yet the help messages specify the practical defaults, not the number used internally (except for --limit-rate, but this option and command has unconventional behavior, setting a symmetric limit as opposed to limiting the total bandwidth).

Below is the current output of monerod --help:

  --out-peers arg (=-1)                 set max number of out peers
  --in-peers arg (=-1)                  set max number of in peers
  --tos-flag arg (=-1)                  set TOS flag
  --limit-rate-up arg (=8192)           set limit-rate-up [kB/s]
  --limit-rate-down arg (=32768)        set limit-rate-down [kB/s]
  --limit-rate arg (=-1)                set limit-rate [kB/s]

Addresses the remark made in #9275.

The inability to have an unlimited number of peers and bandwidth using daemon options could be purposeful. If so, it would be worth documenting this, and if not, further modifications could be made to allow this.

Commits formatted as requested per #10291.

@S5NC
Copy link
Author

S5NC commented Feb 5, 2026

The inability to have an unlimited number of peers and bandwidth using daemon options could be purposeful.

I find the differing behavior of -1 confusing. If I decide I want an unlimited number of out peers after experimenting in daemon console by running out_peers -1, I would except --out-peers -1 as a daemon option to have the same effect.

One solution could be making -1 mean unlimited as a option with flag omission loading the default, and in the console adding default to restore the default value (or by calling the set command without arguments). However, these additional changes would be breaking. Some node operators could be passing the meaningless -1 argument as a daemon option, and I am sure they wouldn't appreciate an unexpected change.

I would opt for clarifying the current varying behavior of -1 in the relevant documentation and help messages, but is there a documentation developer who knows how to convey this in the help messages without adding a large repetitive clump of text?

@nahuhh
Copy link
Contributor

nahuhh commented Feb 5, 2026

-1 means default, not unlimite

default (-1) for in-peers is unlimited
default (-1) for out-peers is 12
so on an so forth

afaict, -1 never is intended to mean unlimited — there isnt a differing meaning among flags. It always means default (ie unchanged)

@S5NC
Copy link
Author

S5NC commented Feb 8, 2026

-1 means default, not unlimited

default (-1) for in-peers is unlimited default (-1) for out-peers is 12 so on an so forth

afaict, -1 never is intended to mean unlimited — there isnt a differing meaning among flags. It always means default (ie unchanged)

So one issue is that the help message says -1 is the default value, but this isn't very informative, saying 12 is better, like --limit-rate-up and --limit-rate-down in the original post's message. Furthermore, actually passing -1 sets it to unlimited, not 12. This PR changes the help message.

And from your comments it seems that running out_peers -1 in the console shouldn't set its amount to unlimited, unlike what currently happens as demonstrated by console feedback (and the actual number of connections reported by status).

out_peers
Max number of out peers set to 12

out_peers -1
Max number of out peers set to unlimited

Because of the above output and my previous experience using CLI tools, I was under the impression that -1 meant unlimited. However, limit_up -1, limit_down -1 both set their respective values to default, and limit -1 sets both to their default values, not unlimited. At the end of the day, confusion in the console when setting values is a minor issue, as the assigned value is reported back to the user. Daemon options don't confirm their effect, but if the behaviour is working as intended there's no requirement for further changes.

@S5NC
Copy link
Author

S5NC commented Feb 8, 2026

Issue describing limit -1 confusion: #6683

@nahuhh
Copy link
Contributor

nahuhh commented Feb 9, 2026

So one issue is that the help message says -1 is the default value, but this isn't very informative, saying 12 is better,

    const command_line::arg_descriptor<int64_t>     arg_out_peers = {"out-peers", "set max number of out peers", -1};

Furthermore, actually passing -1 sets it to unlimited, not 12. This PR changes the help message.

i can confirn that interactively setting out_peers -1 actually sets to unlimited.. :/

And from your comments it seems that running out_peers -1 in the console shouldn't set its amount to unlimited, unlike what currently happens as demonstrated by console feedback (and the actual number of connections reported by status).

out_peers
Max number of out peers set to 12

out_peers -1
Max number of out peers set to unlimited

Because of the above output and my previous experience using CLI tools, I was under the impression that -1 meant unlimited. However, limit_up -1, limit_down -1 both set their respective values to default, and limit -1 sets both to their default values, not unlimited.

yep :/. The way the limit_* is set, is how i thought out_peers worked as well.
agreed that its a mess

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

3 participants