Title: Bandwidth management in go-IPFS
Author: Solène
Date: 18 April 2021
Tags: ipfs
Description:
# Introduction
In this article I will explain a few important parameters for the
reference IPFS node server go-ipfs in order to manage the bandwidth
correctly for your usage.
# Configuration File
The configuration file of go-ipfs is set by default to
$HOME/.ipfs/config but if IPFS_PATH is set it will be
$IPFS_PATH/.config
# Tweaks
There are many tweaks possible in the configuration file, but there are
pros and cons for each one so I can't tell you what values you want. I
will rather explain what you can change and in which situation you
would want it.
## Connections number
By default, go-ipfs will keep a number of connections to peers between
600 and 900 and new connections will last at least 20 seconds. This
may totally overwhelm your router to have to manage that quantity of
TCP sessions.
The HighWater will define the maximum sessions you want to exist, so
this may be the most important setting here. On the other hand, the
LowWater will define the number of connections you want to keep all the
time, so it will drain bandwidth if you keep it high.
I would say if you care about your bandwidth usage, keep the LowWater
low like 50 and have the HighWater quite high and a short GracePeriod,
this will allow go-ipfs to be quiet when unused but responsive (able to
connect to many peers to find a content) when you need it.
(HTM) Documentation about Swarm.ConnMgr
## DHT Routing
IPFS use a distributed hash table to find peers (it's the common way to
proceed in P2P networks), but your node can act as a client and only
fetch the DHT from other peer or be active and distribute it to other
peer.
If you have a low power server (CPU) and that you are limited in your
bandwidth, you should use the value "dhtclient" to no distribute the
DHT. You can configure this in the configuration file or use
--routing=dhtclient in the command line.
(HTM) Documentation about Routing.type
## Reprovider
### Strategy
This may be the most important choice you have to make for your IPFS
node. With the Reprovider.Strategy setting you can choose to be part
of the IPFS network and upload data you have locally, only upload data
you pinned or upload nothing.
If you want to actively contribute to the network and you have enough
bandwidth, keep the default "all" value, so every data available in
your data store will be served to clients over IPFS.
If you self host data on your IPFS node but you don't have much
bandwidth, I would recommend setting this value to "pinned" so only the
data pinned in your IPFS store will be available. Remember that pinned
data will never be removed from the store by the garbage collector and
files you add to IPFS from the command line or web GUI are
automatically pinned, the pinned data are usually data we care about
and that we want to keep and/or distribute.
Finally, you can set it to empty and your IPFS node will never upload
any data to anyone which could be consider as unfair in a peer to peer
network but under some quota limited or high latency connection it
would make sense to not upload anything.
(HTM) Documentation about Reprovider.Strategy
### Interval
While you can choose what kind of data you want your node to relay as a
part of the IPFS network, you can choose how often your node will
publish the content of the data hold in its data store.
The default is 12 hours, meaning every 12 hours your node will publish
the list of everything available for upload to the other peers. If you
care about bandwidth and your content doesn't change often, you can
increase this value, on the other hand if you may want to publish more
often if your data store is rapidly changing.
If you don't want to publish your content, you can set it to "0", then
you would still be able to publish it manually using the IPFS command
line.
(HTM) Documentation about Reprovider.Interval
## Gateway management
If you want to provide your data over a public gateway, you may not
want everyone to use this gateway to download IPFS content because of
legal concerns, resource limits or you simply don't want that.
You can set Gateway.NoFetch to make your gateway to only distribute
files available in the node data store. Meaning it will act as an
http·s server for your own data but the gateway can't be used to get
any other data. It's a convenient way to publish content over IPFS and
make it available from a gateway you trust while keeping control over
the data relayed.
(HTM) Documentation about Gateway.NoFetch
# Conclusion
There are many settings here for various use case. I'm running an IPFS
node on a dedicated server but also another one at home and they have a
very different configuration.
My home connection is limited to 900 kb/s which make IPFS very
unfriendly to my ISP router and bandwidth usage.
Unfortunately, go-ipfs doesn't provide an easy way to set download and
upload limit, that would be very useful.