Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Reconnect overhaul #792
Push Session (aka Continuous Pushes)
Add a push session instance will send pushes continuously until an undefined goal has been achieved which needs to call the
The push session will stop and reject the returned promise in case the push relay determined a client error (e.g. an invalid push token). In any other case, it will continue sending pushes. Thus, it is crucial to call
With default settings, the push session will send a push in the following intervals: 0s, 2s, 4s, 8s, 16s, 30s (maximum), 30s, ...
The default settings intend to wake up the app immediately by the first push which uses a TTL of 0, indicating the push server to deliver now or never. The mid TTL tries to work around potential issues with FCM clients misinterpreting the TTL as don't need to dispatch until expired. And the TTL of 90s acts as a last resort mechanism to wake up the app eventually.
Device Unreachable Dialog
Instead of redirecting to the welcome page (Android) or doing nothing and letting the web client remain in a limbo state (iOS), the push session will retry waking the device three times. If that is unsuccessful, it will show a new dialog that allows to either retry or reload page. This dialog will disappear automatically once a connection to the device has been established.
Fast Session Recovery
When the connection to the app is already lost but there was no explicit closure, we previously had to wait until the SaltyRTC server or the underlying transport recognised that the connection has been lost.
With this change, we request a connectionAck and send a push after 3 seconds of silence (no incoming chunks). This has a cooldown phase of 10 seconds.
Note: This only affects iOS at the moment.
5 times, most recently
Apr 30, 2019
May 9, 2019
7 checks passed
@lgrahl: Today I could again reproduce #106 (12%) with https://web-beta.threema.ch. However, in this case the session could not even reconnect when I touched the smartphone and opened Threema. The session I cannot reconnect to is displayed as follows:
Here's the log (while it's stil at 12 %):
Relevant logs from web application
referenced this pull request
May 12, 2019
@ovalseven8 this is out of scope regarding the client-side implementation, but a quick summary:
It seems that the app still thought it was connected when it received the pushes, and therefore ignored them. We have a system of storing "pending wakeups" in the app though, that should be processed once the connection is actually lost. However, in this case the state machine goes directly from CONNECTING to ERROR. Unfortunately, the pending wakeups are processed in the DISCONNECTED state, which is skipped (since there was never a connection).
Furthermore, the connect timeout in the app is quite long (42s). Maybe that could be reduced by a pending wakeup.
@lgrahl maybe you want to take a closer look. I've filed an internal issue for this.