Thread Rating:
  • 0 Votes - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Keeping connections alive over control point suspend/resume
13-01-2012, 01:25 PM
Post: #1
Keeping connections alive over control point suspend/resume
I'd like to understand what's supposed to happen if a control point suspends and resumes while it has an active connection with a device.

Let's take this scenario as an example:
CP connects to Device at time T0
CP suspends (or disconnects from the subnet) at time T1
Device sends ssdp:alive at time T2
Device sends ssdp:alive at time T3
CP resumes (or reconnects to the subnet) at time T4
CP checks whether Device is still alive at time T0+1800s

At time T0+1800s, would the ohNet control point stack for CP assume that Device is no longer alive and remove it? Or would the ohNet control point stack for CP automatically send out an M-SEARCH at time T4 when CP reconnects to the subnet? If the ohNet stack doesn't do this, should the CP application be monitoring subnetChanged events and initiate a refresh at time T4 to ensure that an M-SEARCH is sent out?
Find all posts by this user
13-01-2012, 01:36 PM
Post: #2
RE: Keeping connections alive over control point suspend/resume
It is left to client code to listen for subnetChanged events and refresh device lists.

There isn't any way to refresh subscriptions (you'd need this as the device stack will remove your subscription if it failed to connect to your event server while your CP was suspended) . You can achieve the same effect by calling Unsubscribe() then Subscribe() on all your proxies.

I'll probably add a Refresh() method on Library in future which loops through all device lists and proxies and refreshes them. I won't get around to this terribly quickly though.
Find all posts by this user
13-01-2012, 10:39 PM
Post: #3
RE: Keeping connections alive over control point suspend/resume
(13-01-2012 01:36 PM)simonc Wrote:  It is left to client code to listen for subnetChanged events and refresh device lists.

There isn't any way to refresh subscriptions (you'd need this as the device stack will remove your subscription if it failed to connect to your event server while your CP was suspended) . You can achieve the same effect by calling Unsubscribe() then Subscribe() on all your proxies.

I'll probably add a Refresh() method on Library in future which loops through all device lists and proxies and refreshes them. I won't get around to this terribly quickly though.

Thanks for the quick reply. This description didn't seem to match what I had observed (possibly because I hadn't phrased the question quite correctly), so I've been digging deeper into the ohNet code. Here's what I found:

1. Suspend and resume are equivalent to disconnecting from and reconnecting to the current network interface.

2. Suspend/disconnect causes CpiDeviceListUpnp::HandleInterfaceChange to be called, which calls RemoveAll(). This removes the currently active device immediately and sends a deviceRemoved() callback to the application.

3. Resume/reconnect also causes CpiDeviceListUpnp::HandleInterfaceChange to be called, which calls Refresh(). This sends out an M-SEARCH request and the (still active) device responds to this, which causes the control point to re-add the device that it removed in step 2 and send a deviceAdded() callback to the application.

4. The application doesn't need to listen for subnetChanged or initiate a refresh, because its deviceRemoved() and deviceAdded() handlers should already do what's needed to re-establish communication with the device and restart the subscriptions.

Given this behaviour, I don't think there would be any benefit in adding a Refresh() method on Library.
Find all posts by this user
16-01-2012, 10:22 AM
Post: #4
RE: Keeping connections alive over control point suspend/resume
Suspending/resuming seems to generate subnetChanged messages reliably on Windows and Mac but its not guaranteed to happen on all variants of these platforms or on other possible CP platforms (e.g. iOS, Android, ...). Its good if your use case is covered by current desktop behaviour but I think I'd still like to add the Refresh() option in future.
Find all posts by this user
16-01-2012, 11:22 AM
Post: #5
RE: Keeping connections alive over control point suspend/resume
(16-01-2012 10:22 AM)simonc Wrote:  Suspending/resuming seems to generate subnetChanged messages reliably on Windows and Mac but its not guaranteed to happen on all variants of these platforms or on other possible CP platforms (e.g. iOS, Android, ...). Its good if your use case is covered by current desktop behaviour but I think I'd still like to add the Refresh() option in future.

What's the relationship between ohNet sending a subnetChanged message to the application and CpiDeviceListUpnp::HandleInterfaceChange being called within the ohNet runtime? Could subnetChanged happen without the HandleInterfaceChanged method running, or vice versa?
Find all posts by this user
16-01-2012, 12:01 PM
Post: #6
RE: Keeping connections alive over control point suspend/resume
(16-01-2012 11:22 AM)simoncn Wrote:  What's the relationship between ohNet sending a subnetChanged message to the application and CpiDeviceListUpnp::HandleInterfaceChange being called within the ohNet runtime? Could subnetChanged happen without the HandleInterfaceChanged method running, or vice versa?

Some background might be useful first:
  • ohNet's OS abstraction listens for changes in the list of available network adapters and calls NetworkAdapterList::InterfaceListChanged whenever the list changes.
  • NetworkAdapterList::InterfaceListChanged decides whether the change constitutes a change in the list of available subnets.
  • If the subnet list has changed, internal listeners (such as CpiDeviceListUpnp) are called and carry out whatever processing is necessary.
  • Any external listeners are then called and informed of the change.
When/whether the first point happens is entirely platform-dependent. The other points happen predictably.

In answer to your questions (and some possible follow-ons):
  • subnetChanged cannot happen without HandleInterfaceChanged method running
  • CpiDeviceListUpnp::HandleInterfaceChanged method won't run without subnetChanged also happening
  • NetworkAdapterList::InterfaceListChanged can run without subnetChanged also happening
  • Platforms provide differing levels of support for detecting subnet changes. Mobile platforms may be less helpful than desktops.
  • Linux ports don't currently report any adapter changes.
Find all posts by this user
16-01-2012, 02:36 PM
Post: #7
RE: Keeping connections alive over control point suspend/resume
Thanks very much for this very helpful explanation.

To go back to my original question and scenario that started this thread, from your last bullet it seems that I need to be concerned about this scenario if my control point is running on Linux. A Linux control point would stop receiving ssdp:alive messages for as long as it is suspended, without any indication that this might have happened, and listening for subnetChanged wouldn't help. The only way I could recover from this is for my control point to react to a device being removed by initiating a refresh of the deviceList and resubscribing as necessary.

The same might also apply on mobile platforms, though this isn't currently an issue for me as my control point doesn't support these.

To keep life simple, I would add this code for all platforms. On Windows and Mac it would be redundant but it shouldn't cause any problems.
Find all posts by this user
16-01-2012, 02:49 PM
Post: #8
RE: Keeping connections alive over control point suspend/resume
(16-01-2012 02:36 PM)simoncn Wrote:  To keep life simple, I would add this code for all platforms. On Windows and Mac it would be redundant but it shouldn't cause any problems.

I'd also be happy to accept a Linux implementation of OsNetworkSetInterfaceChangedObserver Smile. I imagine this might need to create a thread and periodically poll getifaddrs, comparing the results to a previously stored version. This type of low-tech approach would have a good chance of also working on Android. It may also work on iOS (a quick scan of its docs was inconclusive).
Find all posts by this user
19-01-2012, 10:10 AM
Post: #9
RE: Keeping connections alive over control point suspend/resume
It's subnetListChanged, not subnetChanged. The misnaming makes reading this discussion quite hard.

Graham
Find all posts by this user
19-01-2012, 10:37 AM (This post was last modified: 19-01-2012 10:41 AM by graham.)
Post: #10
RE: Keeping connections alive over control point suspend/resume
simoncn,

Maybe I'm missing something but you seem to be expecting your control point to successfully manage suspend/resume using the API of ohNet alone. ohNet does not currently have this feature. On Windows and Mac it is a matter of coincidence that it is possible to write control points that successfully handle suspend/resume merely using the subnetListChanged functionality that is part of ohNet. Apparently this coincidence does not extend to Linux.

I have agreed with Simon that we should have the long-term goal of adding suspend/resume handling to ohNet itself. But for the time being it looks like you will need to write application level handlers for suspend/resume that receive these events from the OS directly.

Graham
Find all posts by this user


Forum Jump: