Re: Session cancellation and reconnection

[cc +public-secondscreen]


On Sun, Oct 12, 2014 at 10:10 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Wed, Sep 17, 2014 at 2:58 PM, mark a. foltz <mfoltz@google.com> wrote:
> >> > The order of events is I was thinking:
> >> >
> >> > (1) The page calls joinSession(url) and the Promise is rejected
> because
> >> > there's no screen presenting |url|.
> >> > (2) The page, wanting to connect to |url| , calls joinSession() in a
> >> > setInterval() loop.
> >> > (3) A screen known to the browser begins presenting |url| and the
> >> > browser
> >> > becomes aware of the presentation.
> >> > (4) The page is able to connect to |url| via the loop in (2).
> >>
> >> I still don't think I understand.
> >>
> >> Why would the page attempt to call joinSesssion in a loop?
> >
> >
> > So, I think there are at least two use cases for polling to rejoin an
> > existing presentation.
> >
> > The first is the case you describe below, where a single opening page is
> > connected to the presentation, but was interrupted, and it wants to
> resume
> > presentation transparently to the user.   If the disconnection happened
> > because the page was torn down, then checking joinSession() once on page
> > reload should be fine.  If the disconnection happened because of a
> network
> > hiccup (switching WiFi, etc.), then maybe the page wants to periodically
> > check if connectivity to the presentation becomes available again, and
> use a
> > loop like the one above.
>
> Ah! If there's a network hiccup a connection is lost, I would expect
> that to both result in the session getting disconnected, and that
> navigator.presentation.onavailablechange fires, with .available=false.
>
> Once the hiccup is over, I had expected that
> navigator.presentation.onavailablechange fires again, with
> .available=true. At that point the page could call joinSession again
> in order to reconnect.
>
> So no looping would be needed.
>

If I understand correctly, onavailablechange fires if *any* screen is
available, not just the one screen that a page is using.  In the following
scenario I am not sure the page will be able to detect reconnection:

1) Browser can see two screens, A and B
2) Page connects and presents to A
3) A becomes disconnected because of an issue specific to browser <==> A.
B remains available
4) A becomes available again

Since B remains available throughout, onavailablechange will not fire with
.available=false then .available=true.

However, writing this I wonder if my mental model is correct.
>
> First off, does this match the capabilities of the underlying network
> protocols? I.e. can we detect the presentation device quickly enough
> again once we have connectivity back?
>

In our experience with Cast, once the WiFi interface is up, it will take
anywhere from 3-30 seconds to resume full connectivity from Chrome to
Chromecast.  This includes the time for mDNS discovery and establishing the
TCP socket with authentication handshake.  I can provide some more precise
stats if you are interested.


> Second, calling joinSession() again will yield a new
> PresenationSession object. Maybe we should instead, or in addition,
> have some form of PresentationSession.reconnect() function?
>

If we were to add reconnect(), could you elaborate on the difference in
behavior between joinSession() and reconnect()?


>
> Alternatively, should PresentationSession objects automatically
> reconnect if they were disconnected due to network issues rather than
> either side explicitly calling .close()?
>

Unsure about that, particularly in scenarios where the page functions in
both presentation and non-presentation modes.  For example, after losing
connectivity, the user may have continued playback locally to an advanced
point in a video.  If the presentation session reconnects automatically,
then the user probably doesn't want playback to go back to the TV without
an explicit connection.

This might be handled by adding a "resumed" event/state so the page can
know whether this is an initial connection (requested by the user) or the
resumption of a disconnected session (made automatically by the browser).

m.


> > The other use case is where the presentation expects multiple controlling
> > pages, and e.g. able to advertise its URL and presentation id to other
> > browsers using through some means (a server, etc.)   In this scenario, a
> > page may want to periodically check if the presentation is available as
> the
> > user roams on different networks without requiring a page reload.
>
> This might be true. I feel like we need to take a larger look at how
> the multiple-controlling-pages scenario affects the API.
>


Agreed.


>
> / Jonas
>