5 ms·

> If you have a means to directly navigate IPFS (that is, without using a proxy) What's the requirement for this? Like, is this a me (local config) or them (I

> If you have a means to directly navigate IPFS (that is, without using a proxy) What's the requirement for this? Like, is this a me (local config) or them (ISP connection) issue?

hagbard_c 5y ago
You need access to the internet, that's about it. IPFS can use any transport protocol (see section 3.2 in the whitepaper [1]), it uses a distributed hash table for routing purposes, content addressing to represent objects - these are immutable, once published they're available as long as there is a peer which has the object in cache or 'pinned' (permanently cached). Read the whitepaper and install [2] a node of your own to get a feel of the thing, you'll soon find out it is an amalgamation of earlier peer to peer systems. The go-ipfs daemon tends to be quite busy, it averages somewhere around 30% CPU, 500MB memory, 0.1Mb/s in, 0.04Mb/s out when hosting ~3GB of (self-generated, niche-interest, database-related) files. This busyness is acknowledged by the developers and should be addressed somewhere down the line. [1] https://github.com/ipfs/papers/raw/master/ipfs-cap2pfs/ipfs-p2p-file-system.pdf https://github.com/ipfs/papers/raw/master/ipfs-cap2pfs/ipfs-... [2] https://dist.ipfs.io/ https://dist.ipfs.io/ (get go-ipfs)
- capableweb 5y ago
  > IPFS can use any transport protocol (see section 3.2 in the whitepaper [1]), In theory. In practice, the network (I checked my local node with ~2500 nodes connected to it) is mostly using quic over tcp/udp, more or less 50%/50% split between tcp/udp. > This busyness is acknowledged by the developers and should be addressed somewhere down the line. IPFS has been killing routers[https://github.com/ipfs/go-ipfs/issues/3320 https://github.com/ipfs/go-ipfs/issues/3320] and sending/receiving lots of network traffic[https://github.com/ipfs/go-ipfs/issues/2917 https://github.com/ipfs/go-ipfs/issues/2917] since 2016 and there hasn't been any notable improvements on that front yet. When is "down the line" in reality?
  - hagbard_c 5y ago
    The "router kill" problem is a problem with those routers, not with IPFS, or any other chatty program for that matter. That said, IPFS is chatty and as such not something you'd run on a dial-up line. ADSL 4/1 or higher would be fine though, as long as you get a router which can take the load - just find something that can run OpenWRT and has enough memory and you're set. Of course you don't need to run IPFS to get at IPFS-hosted content, there are plenty of gateways out there (one of them hosted by Cloudflare). Run your own node if you want to have full control over the path between IPFS and your instances, if you want to contribute to the decentralisation of the 'net or if you just like to tinker.
    - capableweb 5y ago
      > The "router kill" problem is a problem with those routers, not with IPFS, or any other chatty program for that matter. It's really hard to be convinced by that argument when go-ipfs is the only software that manages to kill peoples router until people reboot the router, when literally every other piece of software they use work perfectly, even when using bittorrent and other data-heavy protocols.
      - e12e 5y ago
        Kill routers quickly. I've had to reboot various routers over the years when the buffers tracking states grow full (typically sharing a flat with friends where everyone runs torrent, direct connect or similar).
      - hagbard_c 5y ago
        The same problem has occurred with many P2P protocols, just search for 'p2p router crash'. The problem occurs with Bittorrent, DC++, eDonkey and, yes, IPFS - as well as many other applications which open a lot of connections at the same time. This causes the undersized NAT connection tracking tables to overflow upon which the thing will no longer be able to create new connections. I'm rather surprised that you think only go-ipfs causes these problems given that this is a well-known problem with lower-spec or misconfigured consumer routers, cable modems and other similar devices. Sometimes it can be solved by increasing the size of the tables (which often are set to some ridiculously low number like 1024 or 2048 places) if the device has enough memory. If this is not feasible just get a better device with OpenWRT or a similar free software distribution, configure it for 16K connections and it should work.

> If you have a means to directly navigate IPFS (that is, without using a proxy) What's the requirement for this? Like, is this a me (local config) or them (ISP connection) issue?

hagbard_c 5y ago

You need access to the internet, that's about it. IPFS can use any transport protocol (see section 3.2 in the whitepaper [1]), it uses a distributed hash table for routing purposes, content addressing to represent objects - these are immutable, once published they're available as long as there is a peer which has the object in cache or 'pinned' (permanently cached). Read the whitepaper and install [2] a node of your own to get a feel of the thing, you'll soon find out it is an amalgamation of earlier peer to peer systems. The go-ipfs daemon tends to be quite busy, it averages somewhere around 30% CPU, 500MB memory, 0.1Mb/s in, 0.04Mb/s out when hosting ~3GB of (self-generated, niche-interest, database-related) files. This busyness is acknowledged by the developers and should be addressed somewhere down the line. [1] https://github.com/ipfs/papers/raw/master/ipfs-cap2pfs/ipfs-p2p-file-system.pdf https://github.com/ipfs/papers/raw/master/ipfs-cap2pfs/ipfs-... [2] https://dist.ipfs.io/ https://dist.ipfs.io/ (get go-ipfs)

capableweb 5y ago
> IPFS can use any transport protocol (see section 3.2 in the whitepaper [1]), In theory. In practice, the network (I checked my local node with ~2500 nodes connected to it) is mostly using quic over tcp/udp, more or less 50%/50% split between tcp/udp. > This busyness is acknowledged by the developers and should be addressed somewhere down the line. IPFS has been killing routers[https://github.com/ipfs/go-ipfs/issues/3320 https://github.com/ipfs/go-ipfs/issues/3320] and sending/receiving lots of network traffic[https://github.com/ipfs/go-ipfs/issues/2917 https://github.com/ipfs/go-ipfs/issues/2917] since 2016 and there hasn't been any notable improvements on that front yet. When is "down the line" in reality?
- hagbard_c 5y ago
  The "router kill" problem is a problem with those routers, not with IPFS, or any other chatty program for that matter. That said, IPFS is chatty and as such not something you'd run on a dial-up line. ADSL 4/1 or higher would be fine though, as long as you get a router which can take the load - just find something that can run OpenWRT and has enough memory and you're set. Of course you don't need to run IPFS to get at IPFS-hosted content, there are plenty of gateways out there (one of them hosted by Cloudflare). Run your own node if you want to have full control over the path between IPFS and your instances, if you want to contribute to the decentralisation of the 'net or if you just like to tinker.
  - capableweb 5y ago
    > The "router kill" problem is a problem with those routers, not with IPFS, or any other chatty program for that matter. It's really hard to be convinced by that argument when go-ipfs is the only software that manages to kill peoples router until people reboot the router, when literally every other piece of software they use work perfectly, even when using bittorrent and other data-heavy protocols.
    - e12e 5y ago
      Kill routers quickly. I've had to reboot various routers over the years when the buffers tracking states grow full (typically sharing a flat with friends where everyone runs torrent, direct connect or similar).
    - hagbard_c 5y ago
      The same problem has occurred with many P2P protocols, just search for 'p2p router crash'. The problem occurs with Bittorrent, DC++, eDonkey and, yes, IPFS - as well as many other applications which open a lot of connections at the same time. This causes the undersized NAT connection tracking tables to overflow upon which the thing will no longer be able to create new connections. I'm rather surprised that you think only go-ipfs causes these problems given that this is a well-known problem with lower-spec or misconfigured consumer routers, cable modems and other similar devices. Sometimes it can be solved by increasing the size of the tables (which often are set to some ridiculously low number like 1024 or 2048 places) if the device has enough memory. If this is not feasible just get a better device with OpenWRT or a similar free software distribution, configure it for 16K connections and it should work.