Closed JustMaier closed 4 years ago
@JustMaier
You can use https://js.ipfs.io to get some conclusions on this. I started the service-worker-gateway
and went to https://js.ipfs.io/stats . After that, I closed the tab and some minutes later I went once again to https://js.ipfs.io/stats and the uptime was really the uptime of its start.
For going a little deeper, like using pubsub, it is a good question. Can you try it?
@vasco-santos I'm seeing the same thing as you. It appears to be active even hours later, which is actually really surprising to me based off what I'd learned about service workers...
I'll take a stab at creating a pubsub test that I can use to identify whether or not the node is actually available the whole time.
@JustMaier thanks for having a look! Let us know your findings on it
@vasco-santos unfortunately, it seems to be as I suspected. I made a quick and dirty demo of pubsub inside an IPFS service worker. JustMaier/pubsub-service-worker.
It looks like unless the service worker is given consistent work, it will sleep and kill the IPFS node. In the demo, it even slept while I had the tab open.
So the answer is: the IPFS node inside of the service worker does not have reliable uptime and can not be expected to be accessible after a small period of inactivity within the worker. In Firefox, the node goes down as soon as the tab is closed and may even sleep if there are no interactions with the service worker for 30 seconds.
Thanks for your exploration @JustMaier
Really good insights with this. Once I have some time to dedicate to the service-worker-gateway
project, I would like to think about the alternatives as you described on your repo.
Since service workers have an odd life-cycle (only coming online when needed), what is the node uptime like inside of the service worker? I'm concerned about not being able to use custom libp2p protocols and pubsub in the worker without experiencing weird node downtime. Does anyone have any experience with this?