Behavior of a receiving user agent in reconnecting

[tomoyukilabs]

According to 6.3.5 Reconnecting to a presentation in the current spec, when a controlling user agent reconnects to a presentation,

• the user agent searches an existing (closed) presentation connection, otherwise it creates a new presentation connection,
• and the user agent requests a connection to a receiving user agent

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:

• remove the presentation connection from the set of presentation controllers when it is closed
• search the corresponding presentation connection before creating a new one when a new connection request is received

I believe that the latter one looks better in terms of consistency between controlling and receiving sides. WDYT?

[markafoltz]

I see a benefit to the first option. A long lived presentation might generate a lot of closed connections in the PresentationConnectionList, and removing them would allow closed PresentationConnection objects to be discarded.

Questions:

• Do we think developers would want to keep closed connections around in the list for bookkeeping reasons? For example, to keep track of data for previously connected controllers/players, which could be transferred to a new connection if they rejoin the game.

• Do we need to add a connectionremoved event to PresentationConnectionList? Presumably the receiving page will have already added a state change handler to

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.

[tomoyukilabs]

Many thanks, @mfoltzgoogle!

• Do we think developers would want to keep closed connections around in the list for bookkeeping reasons? For example, to keep track of data for previously connected controllers/players, which could be transferred to a new connection if they rejoin the game.

Yes, but developers can use controller's/player's ID at an application layer to recognize reconnection from the same controller, for example.

• Do we need to add a connectionremoved event to PresentationConnectionList? Presumably the receiving page will have already added a state change handler to

No. A close event fired at a PresentationConnection seems to be sufficient.

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.

[markafoltz]

I could see two options to address this:

1. Allow implementations to cap the size of the PresesntationConnectionList. This does not require a normative spec change. Very long running presentations (perhaps accessible through a public kiosk) would run the risk of hitting this limit by filling up with closed connections, and then failing to accept new connections. They could reload themselves periodically to empty the list.

2. Propose and land the spec change to remove closed connections from the set of presentation controllers, which is future proof, but would possibly be another feature at risk in PR given the time frame and implementation resources available.

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.

[schien]

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.

connectionremoved will not be useful because it'll be much efficient to use statechange event. Using connectionremoved mean web page need to do a series of comparison to know what session is removed. No extra value for web developers to use this event instead of statechange.

[markafoltz]

Okay, let's make the spec change. The implementation does't look too difficult on our end.