DAP-ISSUE-133: Fix UPnP events subscription and unsubscription [Network Service Discovery]

DAP-ISSUE-133: Fix UPnP events subscription and unsubscription [Network Service Discovery]

http://www.w3.org/2009/dap/track/issues/133

Raised by: Cathy Chan
On product: Network Service Discovery

This evolves from comment A7 in the consolidated comments in [1]. Follow-up comments are in [2], [3], [4], [5] and [6].

Essentially, the UPnP events subscription and unsubscription steps are not entirely correct. They should be fixed as follows.

- when a NetworkService object representing a local networked service is being added to any service manager for the first time, the UA sets up a UPnP events subscription with that service. The UA also begins to maintain a subscription list of NetworkService objects subscribed to that service.
- subsequently, when a NetworkService object representing the same local networked service is being added to additional service managers, the UA adds the NetworkService object to the subscription list associated with that local networked service.
- when a UPnP event arrives, the UA dispatches a notification event to each of  the NetworkService objects in the subscription list.
- when removing an available service (the local networked service is no longer online), the UA terminates UPnP events subscription associated with that service.
- when adding an available service (the local networked service comes [back] online), the UA re-initiates UPnP events subscription with that service. It also adds all NetworkService objects representing that service to the subscription list.
- when NetworkService objects are being garbage collected, the UA removes the NetworkService object from the corresponding subscription list. If the subscription becomes empty as a result, the UA terminates UPnP events subscription with the corresponding local networked service.

[1] http://lists.w3.org/Archives/Public/public-device-apis/2013Jan/0052.html
[2] http://lists.w3.org/Archives/Public/public-device-apis/2013Feb/0007.html
[3] http://lists.w3.org/Archives/Public/public-device-apis/2013Feb/0040.html
[4] http://lists.w3.org/Archives/Public/public-device-apis/2013Feb/0049.html
[5] http://lists.w3.org/Archives/Public/public-device-apis/2013Feb/0063.html
[6]* http://lists.w3.org/Archives/Public/public-device-apis/2013Feb/0071.html
*The content of [6] was unfortunately not properly archived. The relevant text is included here.
[[Having taken a closer look, this is still not right. The algorithm uses a
"service type in use" flag to determine whether to terminate the events
subscription, whereas something like "service in use" (*not type*) should be
used instead. In other words, you terminate the events subscription if
client is using a particular service, not if no client is interested in the
service type.

Even with that change, the unsubscription process is still a bit messy.
There are actually two trigger points for terminating an events
subscription. The first is when a local networked service gets disconnected
from the network (i.e. becomes unavailable). At that point, the events
subscription is effectively terminated implicitly, as the service would have
no recollection of the existing subscription when it comes back online. In
this case, all the UA needs to do is clean up its internal storage regarding
this subscription, and this should be part of the rule for removing an
available service. Note that to complement this, the UA also needs to
re-establish an events subscription when the local networked service comes
back online, if there are active service managers that include that network
service. This step is currently missing and should be added to the rule for
adding an available service. The second trigger point for terminating an
events subscription is when all the clients interested in that network
service are gone. In this case, regardless of the current status of the
local networked service, the UA would terminate the events subscription by
sending an unsubscribe message. The checking of this trigger point should be
when a service manager is being removed from the list of active service
managers. I believe this belongs to the garbage collection phase.]]

Received on Tuesday, 30 July 2013 21:43:50 UTC