Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Behavior of a receiving user agent in reconnecting #419
According to 6.3.5 Reconnecting to a presentation in the current spec, when a controlling user agent reconnects to a presentation,
On the other hand, 6.7.1 Monitoring incoming presentation connections would imply that the receiving side would always create a new presentation connection (step 2.), regardless of whether the controlling side would use an existing presentation connection or create a new one. I'm afraid that it might cause duplication of presentation connections at the receiving side, since the current spec does not seem to clearly mention behavior of the receiving side in reconnecting, IIUC.
There may be a couple of options like the following:
I believe that the latter one looks better in terms of consistency between controlling and receiving sides. WDYT?
I see a benefit to the first option. A long lived presentation might generate a lot of closed connections in the
Looking at our implementation it would not be terribly difficult to implement this change. However I am not sure it is solving a concrete problem, until we have a case where we have thousands of closed connections. Maybe as a defense against misbehaving controller pages.
For the second option, I am not sure how the receiving user agent would choose which PresentationConnection object to re-use. It has no data to make a match with a previous connection. It seems simplest to construct a new one for each request.
Many thanks, @mfoltzgoogle!
Yes, but developers can use controller's/player's ID at an application layer to recognize reconnection from the same controller, for example.
Okay, I understand that the first option has benefit in terms of implementation and protocol design. Now, my concern is simply that closed presentation connections which are no longer useful for the receiving page still remain in a PresentationConnectionList.
I could see two options to address this:
Landing a spec change in "level 2" to address this could be difficult, since I am not sure how to easily detect content that is dependent on having closed connections in the list, and thus assess the web compatibility risk.
I am leaning towards 2, generally future proofing is better, but welcome input from @schien on this.
Throwing away the closed connection seems to be a better choice from the perspective of implementation. This can also lead to a simpler protocol design for managing the connection lifecycle in browser.