Skip to content

Conversation

@max-baz
Copy link
Contributor

@max-baz max-baz commented Jan 29, 2019

This implements client-side support for wireapp/wire-server#561 and fixes wireapp/wire-desktop#1129

Finally no need to restart Wire after connecting to VPN! 🎉

return {
PING_INTERVAL: z.util.TimeUtil.UNITS_IN_MILLIS.SECOND * 30,
PING_INTERVAL: z.util.TimeUtil.UNITS_IN_MILLIS.SECOND * 5,
PING_INTERVAL_THRESHOLD: z.util.TimeUtil.UNITS_IN_MILLIS.SECOND * 2,
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please note, I increased the amount of 'ping' requests, because we have to wait for the PING_INTERVAL_THRESHOLD before Wire detects network loss, and it was a whole minute. Now it is only 10 seconds, which I personally find acceptable.

The amount of traffic is not increased as much, because we also changed from sending 36 bytes per message (Wire is so much nicer with internet!) to only 4 (ping).

@bennycode
Copy link
Contributor

@maximbaz Thanks for the PR.

Have you considered the following implementation strategy?

  1. Build a very small stack in which you store a PING when you send a PING and where you remove a PING if you receive a PONG
  2. Send PINGs in a predefined interval and stack them
  3. Show the "no internet connection" bar when there are 2 PINGs in the stack (because ideally there can only be one at maximum when the backend responds with a PONG to every outgoing PING)

@max-baz
Copy link
Contributor Author

max-baz commented Feb 4, 2019

The current implementation is essentially the same:

  1. PING is being sent every PING_INTERVAL (5s)
  2. Every time we send a ping we check if a PONG was received within PING_INTERVAL_THRESHOLD (which equals to PING_INTERVAL * 2)

So essentially when we are about to send the 3rd PING and there still have been no PONG, we show the "no internet connection" bar and attempt to reconnect.

@bennycode
Copy link
Contributor

Could the stack idea replace the "received within PING_INTERVAL_THRESHOLD" check?

if (this._pingHasExperiencedSuspiciousInactivity()) {
if (this.hasAlreadySentUnansweredPing) {
this.logger.warn('Ping interval check failed');
return this.reconnect(WebSocketService.CHANGE_TRIGGER.PING_INTERVAL);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done @bennyn, this is now based on a counter (used boolean for readability), a second ping in the stack now causes reconnect as you can see right in this snippet

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Quick question that I cannot seem to answer just looking at the code.
Will the non-time-based solution work in case of the laptop being put in sleep mode?

Previously the time would also tell us if the computer is not active (and thus not sending any ping). This was why time is an important component here.
I believe with this solution, if the computer is put to sleep we will not reconnect automatically.

Now this scenario might actually be covered by the fact that we are going to send pings that are not going to be replied to. Can you confirm this @maximbaz ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've just confirmed that both putting computer to sleep and simply shutting down wifi doesn't affect Wire, when Internet is back Wire does reconnect as expected. However I can also see that Wire is detecting "connection lost" and "connection regained", so when connection is lost, WebsocketService is reset and no pings are being sent. Once "connection regained" occurs, pings are being sent again as expected.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome!! This is a great PR @maximbaz Thanks a lot 👍

@bennycode bennycode merged commit 201e52c into wireapp:dev Feb 5, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

VPN activation prevents messages arriving, while sending is OK

3 participants