Suggestion: allow port to be defined in preconfigured_peers

[Srayman]

Currently preconfigured_peers in config-node.toml only supports adding IP's or DNS entries. The default node port is used to establish initial connections.

When setting up a local network, if the default port is changed via "peering_port" in config-node.toml on the primary node then other nodes will not be able to establish a connection since they only try the node port that is set either through ENV settings or coded into the node.

[dsiganos]

Currently preconfigured_peers config only accepts ip addresses and dns names. It does not allow for the specification of ports. When I tried yesterday to setup a private network of 2 nodes, I really needed that feature, it would have made my life so much easier. And it needs to be easy, for productivity’s sake, to setup a local network of 2 nodes without having to do tricks. We could trivially add support for address and port in preconfigured peers by allowing a port number as an optional postfix parameter. That means it will be backwards compatible and fairly easy to use and clear. For example: Peer is at address 1.2.3.4 and port 1075

preconfigured_peers = ["::ffff:1.2.3.4,1075"]

The use of a comma to separate the address from the port would make the parsing trivial. However, the use of a comma is controversial. the core team would prefer to use the more standard ":" notation. But the colon notation does not work well with IPv6 addresses. A solution for the use of a colon, is to apply the same workaround people use for using IPv6 addresses with ports. To wrap the address part inside square brackets when specifying the port: [::ffff:1.2.3.4]:1075.

This is an example of some of the different ways the address and port could be specified using the colon plus square brackets rule:

preconfigured_peers = [
    "1.2.3.4",
    "::ffff:1.2.3.4",
    "google.com",
    "[1.2.3.4]:1075",
    "[::ffff:1.2.3.4]:1075",
    "[google.com]:1075"
]

A different configuration entry, the node.work_peers uses address and pair notation separated by a colon. However, that always requires the port part to exist. The port and port separator colon are not optional. So that one is easier to parse and not applicable in preconfigured_peers case where we also want to preserve backwards compatibility. However, the work_peers could be extended to operate in a more flexible manner like the preconfigured_peers and reuse the parse functionality of preconfigured_peers.

[clemahieu]

Relevant RFC https://www.ietf.org/rfc/rfc2732.txt I think we should only use the square brackets in the same way it would be used for an ipv6 address in the browser i.e. they wouldn't be used for ipv4 or DNS names.

http://[FEDC:BA98:7654:3210:FEDC:BA98:7654:3210]:80/index.html http://[1080:0:0:0:8:800:200C:417A]/index.html http://[3ffe:2a00:100:7031::1] http://[1080::8:800:200C:417A]/foo http://[::192.9.5.5]/ipng http://[::FFFF:129.144.52.38]:80/index.html http://[2010:836B:4179::836B:4179]

[JerzyStanislawski]

I'll take a look at this.

[JerzyStanislawski]

The addresses used as configuration entries are formatted as:

• <server>:<port> for work_peers and secondary_work_peers fields. The port is mandatory, the entry will be ignored if not provided.
• <server>[:<port>] for preconfigured_peers field. The port is optional.

<server> is either DNS name or IP address. Both IPv4 and IPv6 are supported. In case of IPv6 it must be wrapped with square brackets if provided with port. Without port square brackets are optional.

Example entries are shown in below table:

work_peers/secondary_work_peers	preconfigured_peers
peering.nano.org:8076	peering.nano.org:7075
	peering.nano.org
192.168.1.1:8076	192.168.1.1:7075
	192.168.1.1
[FEDC:BA98:7654:3210:FEDC:BA98:7654:3210]:8076	[FEDC:BA98:7654:3210:FEDC:BA98:7654:3210]:7075
	[FEDC:BA98:7654:3210:FEDC:BA98:7654:3210]
	FEDC:BA98:7654:3210:FEDC:BA98:7654:3210