Corrupted application state from stale connections

[snez]

This is a cross-post from http://stackoverflow.com/questions/12395387/how-can-meteor-handle-stale-connections

How to reproduce the issue:
1. Open the same app (from a remote server) in two browser windows.
2. Turn off wi-fi (or 3g) - connection becomes stale because it was not closed from the remote server.
3. Perform a write operation in the first tab (the second tab will of course not update reactively).
4. Turn on wi-fi.
5. Perform a second write in the first tab (the second tab will now update reactively)
6. So the first tab is now in a corrupted state. The first write will never sync to the server, and if the page reloads, that change will be permanently lost.

Not sure if Meteor can already handle this scenario, or should this be a "data validation" feature request?

[debergalis]

I couldn't reproduce this. Could you report on what value "Meteor.status().status" has at each step in the sequence?

[snez]

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.

[n1mmy]

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.

[avital]

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.

[snez]

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..

[glasser]

The sockjs implementations do do some sort of heartbeat already. But they may not be working properly.

[snez]

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..