Exception thrown crashes node if TCP connection gets reset

[fazo96]

Is this expected behavior? I'm asking because if I put a rendezvous server in the bootstrap nodes list and it fails to connect then the process crashes

[mkg20001]

This is a feature, not a bug. (the listener returns an error when the server is unreachable)
Though I'm kind of unsure it it should be that way...

[fazo96]

I think it makes sense to throw an error if a bootstrap node is unreachable but the issue is that there is no easy way to catch it and avoid crashing the whole node.js process.

If I have multiple bootstrap nodes/signalling endpoints and one of them is unreachable I will still be able to operate correctly using other ways, but at the moment the error can't be caught and IPFS shuts itself down.

This means you can't add any websocket-star signalling endpoint if you think it might be unavailable at some point or you risk your application not working anymore for anyone

[mkg20001]

I have written https://github.com/mkg20001/js-libp2p-websocket-star-multi for exactly this reason (currently needs to be updated with the new ws-star fixes)
@diasdavid Can I move that thing into the libp2p org?

[fazo96]

@mkg20001 Looks like this issue became relevant again

Screenshot: http://ipfs.io/ipfs/QmcZev5sELsTmojYMVucNrviUnv1qzBDLKpYkn7Qb2vpTn

The whole js-ipfs node does not work because the connection to one of the rendezvous servers using websocket-star crashes

[fazo96]

@mkg20001 any update on this? Do you think https://github.com/mkg20001/js-libp2p-websocket-star-multi is at least as stable as this module? I could try it instead of js-libp2p-websocket-star and see how it goes

[mkg20001]

Yes, besides a few API differences it is just as stable as this one.
(Edit: ws-star-multi uses the ws-star client internally so it's basically like a try/catch wrapper)