thanks for the pointers all
one concern is robustness in the face of intermittent connectivity on mobile clients, SSE seems to be simpler/more robust here from what I can find out but I’ll probably need to test both
@oliver.mooney both ws and sse hold a tcp socket - i shouldn't think there is much between them in terms of fundamental robustness. one thing that might be better from this perspective with ws is that it's a bi-directional channel, so you can send ping/pongs up and down the socket, so both ends can confirm liveness without waiting for any tcp layer timeouts
@mccraigmccraig I was thinking I’d need to use some keep-alive ping/pongs alright. I was going to do the same with SSE by sending per-client empty msgs at set intervals, but it seems at some point both devolve into polling
@mccraigmccraig SSE has automatic reconnect built-in at the browser level.
https://stackoverflow.com/a/5326159 seems to be a good wiki 🙂
These guys seemed to have issues with disconnection detection with SSEs https://streamdata.io/blog/push-sse-vs-websockets/
that's pretty nice @dominicm - but how long do you have to wait for auto-reconnection to kick in though ? we came to the conclusion with our websockets that we wanted application control over latency/liveness and that tcp timeouts weren't doing what we needed
https://www.html5rocks.com/en/tutorials/eventsource/basics/ looks like it's 3s by default, and you can alter it via a message from the server.
but how long before it recognizes that a connection is "dead" - e.g. when you wonder into an area of GPRS connectivity your connection might still be technically alive, but packet latency can go up to many seconds or even 10s of seconds - we would consider such a connection dead and report to the user that they are disconnected
as i understand it, SSE doesn't give the client any way of sending further info to the server after the initial connection, so unless there's a way of specifying "consider the connection dead unless i get some traffic on it at least every N seconds" you might be waiting a while for a tcp timeout on a mobile network
FWIW when we redeploy our server, my browser app reconnects automatically after a while, which is very nice. Didn’t have to create logic for this. I only use it for notifications, so a second delay is perfectly fine for this use case
I noticed that when a client disconnects the channel is closed after a while, so this is how you can discover disconnections. Not sure how Aleph implements it