IPFS objects sometimes take a very long time to load

[chrispanag]

When we load an article or comment on the frontend, sometimes it takes a very long time to load (seems like an infinite amount of time but actually it's not). In some occasions, a refresh seems to solve the problem and make the post/comment load faster.

After some fiddling around with IPFS I discovered the following:

1. What happens when a post takes a long time to load is IPFS searching it through the "wrong" route, basically it initiates the search from a peer far from the peer that contains the actual data.
2. A refresh seems to solve that (sometimes) because with a refresh the search restarts and sometimes it follows the correct route to find the data.

A possible solution/workaround is to only add OUR IPFS nodes in the "bootstrap" field of the IPFS node. (for now only test-node and alpha-b).

IMO we should also try out running our own web-rtc star server and see how this affects peering.

[dgrisham]

A possible solution/workaround is to only add OUR IPFS nodes in the "bootstrap" field of the IPFS node. (for now only test-node and alpha-b).

Definitely this -- I've done this when using IPFS between my laptop and desktop, makes discovery way faster + more reliable.

[ashutosh1206]

I am getting this error in my console logs once in every few seconds, on alpha.capsule.social and also on localhost:

WebSocket connection to 'wss://node0.preload.ipfs.io/p2p/QmZMxNdpMkewiVZLMRxaNxUeZpDUb34pWjZ1kZvsd16Zic' failed:

This could be relevant? Possibly some latest update of ipfs package that is causing this?

Also this error in console log, but doesn't occur as often as the previous one:

POST https://node0.preload.ipfs.io/api/v0/refs?r=true&arg=QmbwSdYfkxPLy5kE4d1VHrMqXwsuPzeGhDmikEN7AoDRy8 403

Maybe this is specific to my machine, but idk. Worth taking a look I guess?

[chrispanag]

These preload nodes are sometimes up/down depending on their load etc.

It's not relevant because IPFS gracefully switches to other nodes.

[chrispanag]

There are a few changes implemented to mitigate this. We are still monitoring this...

[chrispanag]

I haven't seen the problem manifesting now. I will close this but if anyone finds this issue again, please reopen.

[chrispanag]

This seems to occur again from time to time.

I have seen that sometimes web socket connections drop. There could be two reasons why this is happening:

1. After a long idle period of the node the browser drops the connection
2. Because of nginx in the server dropping the connection after a certain amount of time.

Both will need to be investigated.

[chrispanag]

#391 might help here. I see some improvement, please report if otherwise

[jackdishman]

I looked into this issue again today and can't find any instances where a post page encounters an infinite loading loop. This issue may be resolved

[chrispanag]

Reopening this, as we have started receiving reports of the same behaviour again.

[tess3]

User update about pages not loading: "reloading the accessed pages did not help. The pages are not loaded. I am accessing the page from Germany, using Firefox with UBlock Origin, Privacy Badger and HTTPS Everywhere."

[chrispanag]

User update about pages not loading: "reloading the accessed pages did not help. The pages are not loaded. I am accessing the page from Germany, using Firefox with UBlock Origin, Privacy Badger and HTTPS Everywhere."

This specific report is related to this: https://bugzilla.mozilla.org/show_bug.cgi?id=1755692 (a Firefox browser bug).

[nadimkobeissi]

To what extent did adding our own bootstrap nodes fix this issue?

[chrispanag]

it makes it occur less frequently. (and also improves resource consumption - no need to traverse the whole ipfs network to reach our nodes)

One of the next things @dgrisham will research is how this could be improved so that our web socket connections don't "hang" from the browser to our ipfs nodes.

[chrispanag]

More fixes there on #785, we'll monitor for issues.

fix: update IPFS websocket reconnect logic

Previously, the _maintainConnection() function would disconnect and reconnect
to all bootstrap nodes every 10 seconds. One of the issues we had was that the
call to node.swarm.connect() would occasionally throw an error that we didn't
catch, so the _maintainConnection() function would die. This commit adds a
try/catch around the error.

Additionally, this commit checks the nodes that we're already connected to, and
only attempts to reconnect to any bootstrap nodes that we disconnected from at
some point.