Fork me on GitHub
#yada
<
2018-11-01
>
OliverM10:11:59

thanks for the pointers all

OliverM10:11:34

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

mccraigmccraig11:11:59

@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

OliverM11:11:43

@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

dominicm11:11:55

@mccraigmccraig SSE has automatic reconnect built-in at the browser level.

OliverM11:11:43

These guys seemed to have issues with disconnection detection with SSEs https://streamdata.io/blog/push-sse-vs-websockets/

mccraigmccraig11:11:27

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

dominicm12:11:37

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.

mccraigmccraig12:11:15

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

mccraigmccraig12:11:43

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

borkdude15:11:59

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

borkdude15:11:41

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