What triggers a call to channel disconnect (i.e. /_ah/channel/disconnected) when you are using Google Channels API?

[NP]

Hi,

I'm using Google Channels API and have setup the handlers for channel connect and disconnect. However, I still don't know all the conditions which can trigger a channel disconnect (i.e. a call to /_ah/channel/disconnected). Can anybody help out?

Thanks 

[Nick]

It's supposed to be called when the channel is disconnected (I know, right?).

Typically this will be the browser session ending (window close or navigate away), but also the client disconnecting using the js api.

Disconnected and connected aren't actually called from the client, they're basically webhooks from the channel infrastructure, they seem pretty reliable.

If disconnected gets called, I would take that as the channel token is no longer valid, so even if the client is still there it should create a new channel. Make sure you put an exponential backoff on that operation, a simple bug there can overwhelm your servers with even a small number of js clients.

You probably know channels were recently deprecated, so if you're just starting now it might be better to turn to firebase or a saas alternative.

[George (Cloud Platform Support)]

The disconnect detection is performed by a Web Connection Server.

There is no agreed-upon error-free detection strategy for a disconnection in the browser. To determine that a channel has been disconnected, one has to rely to a set of different methods for getting informed faster. These methods all ultimately rely on a "heartbeat" approach, whereby the browser is expected to provide a "heartbeat"-type signal within a fixed cycle. If one doesn't receive any heartbeat signal for some time, the assumption is that the browser got meanwhile disconnected. Based on the needs of the individual application, the rhythm of the heartbeat can be tuned satisfactorily.

Different browsers behave differently when a disconnection occurs, so a generally valid notification method has to be implemented following the above guidelines, effective for all browser models.

It is important to keep in mind that support for the Channel API will be turned off on October 31, 2017. The better product to replace the Channel API is the Firebase Database.

For certain applications, Firebase Cloud Messaging would be the appropriate solution, as an alternative to some of the Channel API functions. For your purpose in particular, managing presence would be the one important feature of Firebase.

[NP]

Thanks for the response. 

My experience so far has been that the disconnect/connect has been unreliable. I noticed sometimes that if I refresh my page, I see a connect action in the logs without a disconnect entry at all or sometimes the disconnect comes after it.

I've also noticed that sometimes when I have the tab open for a while but no messages are coming in, I see a disconnect in the log. My assumption had been that once I made the connection to the channel and it hadn't expired, I shouldn't see a disconnect if I do not navigate away from the page.

[NP]

Hi George,

Thanks for your response. Yes, I'm aware that Channels API will be turned off in October, but since I had already started working with Channels API before the announcement came, I wanted to quickly finish the development using Channels and see if I'm able to meet my functionalities. In addition, I briefly checked out the Firebase Database and it seems it is more expensive than the Channels API so I'm going to take some time to decide if I still want to move over to it.

So far, I feel like the calls to disconnect and connect are not reliable or maybe I'm the one not using it correctly. Instead of waiting for a hearbeat-signal from the browser, if I send one from the server (like a keep-alive signal) every few seconds (2 -3 secs), will that serve to keep the connection alive?

[George (Cloud Platform Support)]

There is no doubt about the fact that browser disconnect is unreliable and difficult to trace in real time. The level of inconsistency and the particularities of possible disconnection detection differ from a browser to another.

A heartbeat script causes the web browser to send a signal to the server at regular intervals to advise that a page from that server is still being displayed. There are numerous examples to be found, with various implementations of the heartbeat principle.

Detecting that a channel is still alive, as sketched above, is different from trying to keep it alive by programmatic means. Sending regular signals from the server might not help when a token expires, to name an example. You need to decide what architecture suits best your needs.

Firebase Database pricing might seem high at a first look, but one has to to take into consideration the total usage volume planned. In comparison to other solutions, it may prove advantageous in that context.

[Nick]

Managing the connection on the client side is not as simple as the server. The following may be useful:

The dev server simulates channels by polling, so it isn't a great guide for how it works in the live environment.

Channels only last about 20 minutes. On the client, pull get the js error callback, just establish a new connection and continue. If this seems to have some issues, there are some hacks published to stack overflow that seem to make reconnecting more reliable.

Disconnect is mostly reliable, but it's probably only useful for cleaning up data on the server. If you want to drive behavior, I'd rely on the client making requests based on the js callbacks for onclose and onerror.

Once you client side and server side code is bedded down it's very reliable and robust.

[NP]

Nick,

You said --- If you want to drive behavior, I'd rely on the client making requests based on the js callbacks for onclose and onerror.....Thanks for that tip. It has given me a gem of an idea.

You also said Channels only last about 20 minutes. I was under the impression that when you create a channel, you can specify a time limit up to 24 hours. Are you saying this is incorrect or this is for something else?

[NP]

Thanks George.

[Nick]

Re duration, like all things in appengine it has changed over time. My recommendation would be to write some js logging code when you've got it working and leave it running over a weekend, I'd be interested to see the results.