This is a cross-post from http://stackoverflow.com/questions/12395387/how-can-meteor-handle-stale-connections
How to reproduce the issue:
Not sure if Meteor can already handle this scenario, or should this be a "data validation" feature request?
I couldn't reproduce this. Could you report on what value "Meteor.status().status" has at each step in the sequence?
It stays as "connected" as well. I am testing this on http://jqm.meteor.com/ (which is Meteor 0.4) - I go there, turn off wi-fi (on OS X Lion), then check Meteor.status().status from the browser console.
I was able to reproduce on 0.4.0 and on devel using the todos app. This looks like a regression, meteor is supposed to re-transmit all the updates that were done while disconnected an re-sync the state.
We also repro'd this using todos. It seems that one of the tabs thinks it's sent methods to the server when in fact it hasn't. Method replay on reconnect should handle this correctly but it apparently doesn't.
This may need some work on a low level, a ping packet should be periodically sent to the server through the open websocket, which in turn should respond with a pong. If a pong is not received within say 1 minute, any data that has been sent to the server since the last pong should be validated with the server..
The sockjs implementations do do some sort of heartbeat already. But they may not be working properly.
I think they do work because after a while Meteor.status().connected does become false, presumably as a result of the sockjs heartbeat implementation. However as a solution it may still not be robust enough because data transmitted while the connection was stale may have been lost and neither the server nor the client will check that.
I would think that a robust solution would be to perform some sort of 2 way handshake when sending data, i.e. send 1k of data from the client and ask the server if it received that data - then if the server replies with 1024 bytes received, then the transmission has been validated..
Don't drop method calls on the floor shortly after connectivity loss.…
… Fixes #339
Update sockjs to 0.3.4. This removes the meteor patch from #339, but …
…preserves the patch to do http->https on IE.