Ipfs config Peering.Peers modification and effect?

1

I recently discovered Peering.Peers config

I would like to use it to enhance swarm connectivity quality.
I cannot succeed using ipfs config --json to change it with a jq prepared file?
Does the effect is needing daemon restart or it is reloaded automatically?

Does anyone already uses this parameter?

Thanks for your help

2

I use it to keep my laptop and my desktop connected whenever they are both up, it works great. The first thing you need to know is that you need to control both sides and that both need to have peering entries pointing at each other. Never have one sided peering, it only leads to grief. Second, yes, you need to restart after changing the config file for the changes to take effect. Third, here is what it looks like on one of my nodes (I redacted the ID):

"Peering": {
	"Peers": [
		{
			"Addrs": [],
			"ID": "12D3KooW..."
		}
	]
},

You don’t need to enter addresses if your node is able to connect to the network, it will use the network to look up the addresses for that node (which is key for my laptop, as its address depends on where I am connecting from, which changes). Of course, at least one of the two nodes needs to be able to dial the other, or it will never work. Again, make sure that both ends of a peering agreement are configured.

1 Like
3

Why do both sides need to have a peering section?

I run servers at datacenters and many other IPFS nodes have a peering/peers config file section to point to those datacenters. One side is transient like in your example the other side not.

It makes sense for transient nodes to have a peering section, not so useful for the datacenters (tho they do, and point to each other NOT any transient nodes).

I thought the peering section would get around the need to use the DHT to determine routing and for nodes listed in the peering section of the config file would provide essentially direct routing.

When I initialize a new (transient) node I add the peerIDs for the datacenters then start the new IPFS instance. It definitely doesn’t act like a direct routing path!

4

Peering is a relationship. A one-sided relationship is called stalking. All jokes aside, here is an excerpt from the docs:

Peering can be asymmetric or symmetric:

  • When symmetric, the connection will be protected by both nodes and will likely
    be vary stable.
  • When asymmetric, only one node (the node that configured peering) will protect
    the connection and attempt to re-connect to the peered node on disconnect. If
    the peered node is under heavy load and/or has a low connection limit, the
    connection may flap repeatedly. Be careful when asymmetrically peering to not
    overload peers.

Peering

5

That false btw.
You can peer with someone that doesn’t peer with you.
It is still better for both sides to peer together because then the connection will be stable.

The difference is that if the peering is non-reciprocal the other peer (the one who havn’t added to it’s peering table) will close the connection from time to time because it thinks it is useless.
Then the peered node will reopen the connection right after.

6

I’m not saying you can never use asymmetric peering, I’m saying that, if your goal is to do it with a well known public server, don’t! Please see my other post on the matter, which goes into more details as to why it should not be encouraged:

Peering with a well known server

7

Ok so in the end we agree. :slight_smile:
It’s just that to me “you need” sounds like this is an absolute requirement and if you don’t do symetric peering then it wont work.

8

Yeah, I agree. I worded it that way on purpose though, hoping that it would discourage some from peering with public servers. Anyway, I later pasted from the docs, which clearly state what the exact situation is, and what the potential downside is.

1 Like
9

I’m grateful for the discussion. I came away with the impression “if you don’t do symetric peering then it wont work”.

I used the term “public server”, but it will only be public to those I share the connection info with; there is no public gateway like gateway.ipfs.io is, no proxied interface to port 8080.

My plan stands as sound then and I will continue using the peering/peers section in the config file.

This discussion provides one reason that new nodes can’t ping or connect to my main servers (they’re too busy to respond), but that seems unlikely.

On slightly older nodes I can connect & get files with minimal delay, so I am still at a loss as to why new nodes timeout waiting for a connection to my main servers.

I know there’s a significant bandwidth hit when a new IPFS node is brought online, but that spike should be well past 24 hrs later.