Blacklist? How to prevent other nodes from connected to my node?

Help Coding
1

I’m working on forming a subnetwork of IPFS nodes connected via a custom pubsub channel. Each node in my subnetwork identifies itself, and so nodes that do not identify themselves are clearly not part of the subnetwork. My code runs swarm.disconnect() on those nodes.

What I’ve found is that the non-member nodes that my node is actively trying to disconnect will immediately re-connect. Over time more and more nodes that are not in my subnetwork will connect, and eventually the bandwidth of my node will start to increase significantly.

I have the Routing.Type config setting set to none. I’m running go-ipfs v0.11.0.

It would be great if IPFS had a ‘blacklist’ I could add the problematic nodes to, so that my software isn’t having to play this tug-of-war. I have the server profile set, which populated the Swarm.AddrFilters array. From the documentation, it doesn’t seem exactly like what I’m looking for, in terms of a ‘blacklist’.

Is there some way of banning other nodes from connecting to my node?

2

You should use PNET, or a DHT with a different key.

So both networks wouldn’t try to mix.

1 Like
3

That’s a new idea to me. I’m ignorant. Can you expand on that?

How would I go about implementing either of those ideas?

4

PNET

PNET adds a symetric keying to all connections.

The docs is here: go-ipfs/experimental-features.md at master · ipfs/go-ipfs · GitHub but that not meant for public network, it’s more if you wanted a private private IPFS network.

DHT

An other option is adding a prefix to the IPFS DHT.
There (in both DHTs) :

you can add this option dht package - github.com/libp2p/go-libp2p-kad-dht - pkg.go.dev

This one seems more sane, and is for example what filecoin does.

Blocklist

Both of thoses solutions are far better than using a blocklist.
If other nodes are activelly trying to connect to you that an issue, adding a blocklist would waste bandwidth and ressources because you aren’t stopping the actually issue, just fixing the symptoms and maybe even harm the IPFS network because you would attempt to shard the DHT.

1 Like
5

Thank you!

I can see your logic, about solving the problem and not the symptom. I hadn’t heard of that private network (pnet) feature. It sounds exactly like what I’m looking for!

6

I don’t think PNET is really what you want.

It’s more meant when all nodes are trusted.

For example netflix use it to create a private network to share their docker images to all of their image servers.

7

Also one thing I’ve just thought about.
FYI for both solutions you will need to setup your own bootstrap nodes, it’s not hard just make a few nodes that run 24h/365 and put their address+peerid in the config.

Because the “official” bootstrap nodes wont recognise your nodes as IPFS nodes anymore.

You can’t both disconnect from the network and use the official IPFS bootstraps because that would break and harm the DHT.

8

Forgive me, but what is even the point of a subnetwork in the grand scheme of things? We’ve already had “subnetworks” of mainframes for decades. It’s time to move beyond that, and keep this more inclusive than exclusive.

9

The point of subnetworks is that you can create a smaller DHT with only people running your app.

I don’t think that particularly usefull but if @christroutner want to do it, I don’t know their reasons, I’m explaining how they can.

I’ll let chriss respond why if they want.

10

This isn’t philosophical, it’s mechanical.

The subnetwork is designed to do a very specific thing. It’s not deliberately set up to exclude the wider IPFS network, but if interaction with that wider network is preventing the subnetwork from accomplishing the thing it was created to do, then something has to give. The appropriate thing is to reduce exposure to the wider network, until some happy medium can be achieved.

11

To follow up on this this thread:

Switching the Routing.Type config from dht to none, helped a lot. The nodes on the subnetwork will run well for hours (possibly even days), only connecting to other subnetwork nodes.

What I’ve observed, and appears to be random, is that these nodes will suddenly try to connect to hundreds of other nodes within the span of a few seconds. When this happens, CPU usage spikes to 100% and network bandwidth also spikes. This appears to be due to some low-level part of go-ipfs, and does not appear to have anything to do with my code. And as I also said, it appears to happen randomly, with no detectable pattern in terms of what triggers it.

What makes it worse though, is that one node will slowly ‘infect’ the other nodes on the subnetwork. They’ll also start trying to connect to hundreds of other nodes. The spike in resources will bog them down and cause them to stop responding well to the other nodes in the subnetwork.

The subnetwork is pretty small, and grows slowly. So my solution to this was to hard-code a peer ‘ceiling’. If the ipfs-coord software detects that the node is connected to more than 50 nodes, it will shut down the IPFS node for 10 seconds. This encourages all the other nodes to disconnect from it.

It’s an ugly hack, but so far is solving the problem. This may become less useful as the subnetwork grows. But it’s less extreme than forking the DHT or setting up an isolated, trusted, private network.