Thread Rating:
  • 0 Votes - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
How does the Control Point know if the Device disappears without saying goodbye?
12-10-2012, 06:59 AM
Post: #1
How does the Control Point know if the Device disappears without saying goodbye?
It seems that my Control Point only receives the device removed notification/callback when the Device explicitly removes itself from the network by calling DvDeviceSetDisabled.

In my device, I am catching SIGINT and SIGABRT so that if anything goes wrong, I can disable the device and clean up, and the Control Point will get the removed notification.

However, if the device is simply powered off, the Control Point doesn't receive such a notification and therefore cannot pass on the news to the user that the device has gone AWOL.

Should I be doing something explicitly to poll the device for it's presence?
Am I missing something obvious? Or should I really be getting the removed callback/notification in this scenario?


Happy for your advice...

Doug
Find all posts by this user
12-10-2012, 08:46 AM
Post: #2
RE: How does the Control Point know if the Device disappears without saying goodbye?
When a device announces itself (either multicasting to all/any interested listeners or unicasting a response to a MSEARCH), the announcement includes a MX header which specifies a maximum time before the device sends out another announcement. Typically this will be 1800 seconds (== 30 minutes). If the device does not send another announcement in this time, the control point stack assumes it has been disabled and removes it from any device lists.

So, you'll always be informed that a device has left the network. It just takes longer if the device leaves without sending the normal byebye messages.

If you're using ohNet as a device stack, you can encourage control points to spot this case more quickly by changing the MX value using OhNetInitParamsSetDvMaxUpdateTime(). Be aware that announcements will typically be sent in less than half the MX time and that selecting too low a MX value might be thought of as inconsiderate by other network users.
Find all posts by this user
16-10-2012, 03:30 AM
Post: #3
RE: How does the Control Point know if the Device disappears without saying goodbye?
Hello Simon,

I have set OhNetInitParamsSetDvMaxUpdateTime() to 300 seconds and the Device responds directly to MSEARCHes exactly as you described. However, within that announcement period, I cannot see the Device issue any further multicast announcements, and the Control Point understandably removes it from the Device list.

I am using Device Spy as the Control Point and am also monitoring the Upnp HTTP traffic using Device Sniffer (both Upnp Developer tools from http://opentools.homeip.net/dev-tools-for-upnp).

Am I correctly assuming that I do not need to explicitly issue these announcements from the OhNet DV stack?
Any ideas why it is not issuing the announcements?

Doug
Find all posts by this user
16-10-2012, 08:02 AM
Post: #4
RE: How does the Control Point know if the Device disappears without saying goodbye?
Actually, I don't think this is an ohNet problem. It seems that the NOTIFY announcements don't come through when the Device is in NFS mode. When running from a FFS, they do.

Any suggestions you have on why this might be happening are welcome... it is a bit inconvenient since I need to develop with the device using an NFS.
Find all posts by this user
16-10-2012, 08:06 AM (This post was last modified: 16-10-2012 08:43 AM by simonc.)
Post: #5
RE: How does the Control Point know if the Device disappears without saying goodbye?
(16-10-2012 08:02 AM)dough Wrote:  Actually, I don't think this is an ohNet problem. It seems that the NOTIFY announcements don't come through when the Device is in NFS mode. When running from a FFS, they do.

Any suggestions you have on why this might be happening are welcome... it is a bit inconvenient since I need to develop with the device using an NFS.

What do NFS and FFS stand for?

If they refer to file systems you're using, ohNet doesn't know or care about the style of file system its executable is loaded from. Is it possible instead that firewall rules mean that multicast traffic can't be sent from or received by certain devices on your network?
Find all posts by this user
22-10-2012, 10:55 AM
Post: #6
RE: How does the Control Point know if the Device disappears without saying goodbye?
Yes, they do refer to file systems: NFS (Network File System) and FFS (Flash File System) respectively.

The problem of NOTIFYs seems to be independent of the file system. There are times when the Control Point cannot discover the Device. I recall that when running the OhNet tests on iOS (also the platform of my Control Point), they eventually failed to discover any Devices. Did you manage to investigate this further?

I notice that when the Control Point stack starts or when the Device List is created, the Control Point issues an M-SEARCH for the specific device type. Using Wireshark I can see that the M-SEARCH is issued only once. Other control point tools (both Device Spy & Device Sniffer) seem to issue two M-SEARCHes. Is this likely to reduce the chance of an M-SEARCH going missing (since it is using UDP)? Can I reissue the M-SEARCH once the Device list has been built?

Clearly my Upnp operational knowledge is lacking, but using OhNet, should I need to understand how Upnp works?
Find all posts by this user
22-10-2012, 12:22 PM
Post: #7
RE: How does the Control Point know if the Device disappears without saying goodbye?
(22-10-2012 10:55 AM)dough Wrote:  Yes, they do refer to file systems: NFS (Network File System) and FFS (Flash File System) respectively.

The problem of NOTIFYs seems to be independent of the file system. There are times when the Control Point cannot discover the Device. I recall that when running the OhNet tests on iOS (also the platform of my Control Point), they eventually failed to discover any Devices. Did you manage to investigate this further?

I improved but didn't fully stabilise discovery. I have time scheduled next week to finish this off.


(22-10-2012 10:55 AM)dough Wrote:  I notice that when the Control Point stack starts or when the Device List is created, the Control Point issues an M-SEARCH for the specific device type. Using Wireshark I can see that the M-SEARCH is issued only once. Other control point tools (both Device Spy & Device Sniffer) seem to issue two M-SEARCHes. Is this likely to reduce the chance of an M-SEARCH going missing (since it is using UDP)? Can I reissue the M-SEARCH once the Device list has been built?

We didn't duplicate MSEARCH requests on the assumption that UDP isn't all that unreliable on local networks so requests won't actually get lost very often. If it turns out this is only true for wired networks, we could change device lists to issue repeated MSEARCHes. For now, you can call CpDeviceListRefresh which will issue a new MSEARCH, merging the new and previous lists.


(22-10-2012 10:55 AM)dough Wrote:  Clearly my Upnp operational knowledge is lacking, but using OhNet, should I need to understand how Upnp works?

You shouldn't need to understand implementation details of UPnP. We've found however that you do need to learn a little about network administration to debug deployment issues caused by poorly setup networks.
Find all posts by this user


Forum Jump: