LAN-only peers in a swarm

Help Kubo
,
1

I can’t find any information about this specific use-case from Google, I might just not know the term, but how do I make a single go-ipfs instance into a leech that is only willing to upload to other peers only on the local network?

1 Like
2

Hi! I’m not sure this is possible out-of-the-box. It might be possible to hack go-bitswap to abort sessions to non-lan peers, but I’m not sure how simple this would be.

3

Depends. If the lan is static you can just create a private IPNS network and only add peers which are on your lan.

4

But that effectively isolates me from the rest of the content I might want to access?

5

I opened a GitHub issue for this feature request, https://github.com/ipfs/go-ipfs/issues/6846. I can’t use go-ipfs in this state because the amount of devices I’d use it on would just murder my uplink gruesomely.

6

Ah, so bufferbloat is your problem.

You may want to fix it first, before you request changes to applications because of it.

https://www.bufferbloat.net/projects/bloat/wiki/What_can_I_do_about_Bufferbloat/

7

No, I literally lack the bandwidth to upload.

8

Ok, if this is the problem:

  1. Reduce ConnMgr connection settings
  2. Set your devices to DHT “client” mode
  3. Enable mDNS and ensure it works on your LAN

That should alleviate most of the problems on that regard.

9

If your router have no issues with bufferbloat and do prioritization of the IPFS traffic (when you mark the outgoing traffic with a firewall rule on the nodes) the router should drop everything which is ‘too much’ for your uplink.

Running IPFS won’t affect this way the network performance of other applications nor the latency.

Option 1 and 2 of what @hector pointed out, will reduce the ‘background traffic’ but won’t fix any bufferbloat or prioritization issue in your router setup.

Best regards

Ruben

10

I have other low-priority traffic I do want to get trough before ipfs’s. Maybe if ipfs supported TCP-LP this might be alleviated the best, but I still don’t want it using upload bandwidth without explicit configuration - what if a device of mine is temporarily connected to a metered connection and it starts chugging upload, that’s yet another case such upload speed control seems very important.

11

Okay but this still means a node will try contacting WAN outside nodes, correct?

12

DiffServ allows for 64 different tags for traffic. One might think this is excessive enough to allow for every possible network traffic operation a home user might encounter.

»Maybe if ipfs supported TCP-LP this might be alleviated the best, but I still don’t want it using upload bandwidth without explicit configuration«

TCP-LP is like 17 years old and was never considered to be implemented anywhere before. I doubt it makes sense to implement in IPFS.

Especially if software like sch_cake is readily available which does exactly what TCP-LP wanted to achieve and even more - without any explicit configuration. You need just to flag packages as you please and sch_cake will fully adapt to any network load situation without any reconfiguration.

»what if a device of mine is temporarily connected to a metered connection and it starts chugging upload, that’s yet another case such upload speed control seems very important.«

That’s quite a big what if. If IPFS has implemented what you propose: just local connections you couldn’t connect to anything if you’re on a different network with IPFS, regardless if metered or not.

This may make sense in your specific edge case, but I doubt for anyone else, since operating systems allow for firewall rules to be applied to any connection the network manager uses. If you want to allow ipfs just to your local network when you’re on your local network, just add a firewall rule, that all packages IPFS sends get dropped when addressed to the MAC-Address of your router at home.

If you have a metered connection, create a firewall profile for it and drop any traffic for any application you like to avoid consuming your metered connection data.

Overall I don’t see any reason to implement more network options than currently implemented, because you can easily address your edge case with simple firewall rules, which are much more flexible, since they can be changed by the network manager based on your network connections, and don’t have to be handled by the application.

Edit: Multiple quotes seems to break the post layout. Replaced with simple signs.

13

You’re boldly assuming upstream hardware supports that many, or more than basic configuration. I know mine doesn’t.

This just breaks IPFS totally, it isn’t a solution.

I’m sorry, how is it a big what if? It’s a real-life scenario where IPFS is dangerous to even start up.

I don’t want to nanny the software I have, with some annoying workarounds, that’s nonsense.

Elaborate on this.

Generally though, everything you’ve suggested either breaks IPFS or requires seriously tedious manual labor compared to just having a config parameter that could allow specifying a subnet and it’s upload and download limits. Torrent clients can do this and it works great, so should ipfs.