Go-ipfs: New 0.4.20 swarm connect "important" functionality doesn't work.

[obo20]

Version information:

go-ipfs version: 0.4.20-
Repo version: 7
System version: amd64/linux
Golang version: go1.11.5

Type: Bug

Description:

In the newest release 0.4.20, swarm connection has a new feature stated here:

The ipfs swarm connect command has a few new features:
It now marks the newly created connection as "important". This should ensure
that the connection manager won't come along later and close the connection if
it doesn't think it's being used.

I ran ipfs swarm connect to manually connect two nodes of mine that are both running 0.4.20, and they disconnected minutes later. I've been able to test this multiple times.

[Stebalien]

Thoughts:

• Could be https://github.com/libp2p/go-libp2p-connmgr/issues/10. The issue could be _much_ worse than I had thought.
• Could be some other bug killing connections.

[AndreaCensi]

I also observed this same behavior.

The workaround is to run ipfs swarm connect periodically.

Note: this also happens when the two nodes were synchronizing data between the two of them. The connection was heavily used! (10 MB/s)

Behavior was the same in both directions. (one connecting to the other and viceversa)

[Stebalien]

https://github.com/libp2p/go-libp2p-connmgr/pull/39 may help.

[Stebalien]

Reopening till we can confirm.

[Stebalien]

Confirmed fixed.

[ligi]

I am still seeing this error with 0.4.21:

✗ ~ ipfs swarm connect /ip4/178.19.221.38/tcp/4001/ipfs/QmNmBr4tiXtwTrHKjyppUyAhW1FQZMJTdnUrksA9hapS4u       22:45:18
connect QmNmBr4tiXtwTrHKjyppUyAhW1FQZMJTdnUrksA9hapS4u success
✓ ~ ipfs swarm peers | grep QmNmBr4tiXtwTrHKjyppUyAhW1FQZMJTdnUrksA9hapS4u                                   22:45:21
/ip4/178.19.221.38/tcp/4001/ipfs/QmNmBr4tiXtwTrHKjyppUyAhW1FQZMJTdnUrksA9hapS4u
✓ ~ ipfs swarm peers | grep QmNmBr4tiXtwTrHKjyppUyAhW1FQZMJTdnUrksA9hapS4u                                   22:45:36
/ip4/178.19.221.38/tcp/4001/ipfs/QmNmBr4tiXtwTrHKjyppUyAhW1FQZMJTdnUrksA9hapS4u
✓ ~ ipfs swarm peers | grep QmNmBr4tiXtwTrHKjyppUyAhW1FQZMJTdnUrksA9hapS4u                                   22:45:37
✗ ~ ipfs version                                                                                             22:48:33
ipfs version 0.4.21

the daemon was alive the whole time - no errors there

[obo20]

@ligi Did you run ipfs swarm connect on the second node as well? In order for this to work you need to run the command from both nodes.

[ligi]

no - why do I need to do so? I just want to keep this connection alive to not constantly having to do "ipfs swarm connect" - also from the other side it is not really possible as the other host is behind a NAT - only one (the "server") has a public IP

[obo20]

@ligi This is a mechanism to protect nodes against connection abuse.

For example, think of a high profile node like the main ipfs.io gateway nodes. If possible, everybody would try and maintain a connection to it. But the ipfs.io node most likely doesn't want to stay connected to every node on the planet.

By requiring both nodes to run this command to connect to each other, high profile nodes are protected against forcefully maintaining a connection to every node that runs swarm connect against them.

[ligi]

ah I see - that makes sense - thanks. But could another way to fight abuse not be that I whitelist my client nodes (that then can have a changing IP - but are identified by a signature with their private key?)

[makeworld-the-better-one]

@obo20 How large is the window between both nodes running it? If one connects, and then another runs the command an hour later, will it still work? 5 minutes later? A day?

[obo20]

@makeworld-the-better-one I'm not entirely sure on that. That's probably more of a question for the libp2p team. We always run our connections on node startup, so I can't give you too much insight into how this behaves in non-ideal scenarios

[makeworld-the-better-one]

@obo20 @Stebalien sorry to revive an old thread, but I'm wondering about this idea of both nodes having to run the command. Can you explain some scenarios to me, and whether the connection will succeed or not? I worry I've misunderstood things, as atm I think that a human needs to be running a command on both ends within 30 seconds of each other to actually achieve an intentional connection with a node.

• Node A runs ipfs swarm connect aimed at Node B. B does not have a human on the other end to run the same command, but it hasn't hit its HighWater value for max connections yet.
• A runs ipfs swarm connect aimed at B, but this time B is already at the max number of connections. Will B drop a connection to reply to A, or will nothing happen because there is no human running the command?

[Stebalien]

Node A runs ipfs swarm connect aimed at Node B. B does not have a human on the other end to run the same command, but it hasn't hit its HighWater value for max connections yet.

In this case, the connection _should_ stick.

A runs ipfs swarm connect aimed at B, but this time B is already at the max number of connections. Will B drop a connection to reply to A, or will nothing happen because there is no human running the command?

B will drop the connection after the grace period if it isn't useful.

[makeworld-the-better-one]

Thanks for the quick reply! My follow up question is what determines useful, and why is it "should" haha

[Stebalien]

In this case, the connection should stick.

You may run into https://github.com/libp2p/go-libp2p-connmgr/issues/46 (https://github.com/ipfs/go-ipfs/pull/6558), unfortunately.

[Stebalien]

(feel free to try running that branch (which will be merged to master soon))

[makeworld-the-better-one]

Thanks! I'm still wondering how a node determines a connection is useful though. @Stebalien

[Stebalien]

Services using the connection assign "weight" to every connection they need. We then sum these weights and sort the connections to find the least useful ones. Idle connections should have the _least_ weight so we should trim connections we aren't using first.