org.teleal.cling.protocol.async
Class ReceivingNotification
java.lang.Object
org.teleal.cling.protocol.ReceivingAsync<IncomingNotificationRequest>
org.teleal.cling.protocol.async.ReceivingNotification
- All Implemented Interfaces:
- Runnable
public class ReceivingNotification
- extends ReceivingAsync<IncomingNotificationRequest>
Why does this (control point) protocol implementation ignore anything but root device notification messages?
The UDA 1.0 spec says that if a device comes online, it will send out dozens of advertisement messages.
The general question is: Why would any control point even react to a notification message that is not for a
root device? They don't arrive ordered, and what would you do when you receive a service notification
before you receive its root device notification. You can't use the service anyway... and once you have
the root device notification, go grab the device descriptor and you will find the services. I can only
assume that this was specified so that control points may filter the services they can handle in the
discovery stage, before descriptors are exchanged. Given that there is dozens of messages being exchanged,
I'm not sure what the designers hoped to gain from this. It's certainly very convoluted and they even had
to explain how not to flood the network in UDA 1.1.
The UDA 1.0 spec says (in 1.1.2):
"... order is unimportant, but refreshing or canceling individual messages is prohibited."
So this looks like we can always treat the life cycle of a 'device' as a composite with all
embedded devices and services dependend on that root device. In other words, we don't care if an
'alive' or 'byebye' is announced for an embedded device or a service because as long as the root
device doesn't appear or disappear, nothing changes.
To cause further confusion, the following was added to the UDA 1.1 spec (in 1.3):
"If a control point has received at least one 'byebye' message of a root device, embedded device, or
service, then the control point can assume that all are no longer available."
Well, this control point doesn't care then, as long as the root device has not been 'bybye'd or expired.
"Only when all original advertisements of a root device, embedded device, and services have
expired can a control point assume that they are no longer available."
This could mean that even if we get 'byeby'e for the root device, we still have to assume that its services
are available. That clearly makes no sense at all and I think it's just badly worded and relates to the
previous sentence wich says "if you don't get byebye's, rely on the expiration timeout". It does not
imply that a service or embedded device lives beyond its root device. It actually reinforces that we are
free to ignore anything that happens as long as the root device is not gone with 'byebye' or has expired.
Finally, note that all advertisement messages contain a Location header with the URL of the root
device descriptor. So theoretically we could take any notification message that comes in, grab the device
descriptor, and go off retrieving the really important information. It is however simpler to just do that
for root device advertisement messages and ignore everything else.
ReceivingNotification
public ReceivingNotification(UpnpService upnpService,
IncomingDatagramMessage<UpnpRequest> inputMessage)
execute
protected void execute()
- Specified by:
execute
in class ReceivingAsync<IncomingNotificationRequest>
isRootDeviceMessage
protected boolean isRootDeviceMessage()
isRootDeviceAliveMessage
protected boolean isRootDeviceAliveMessage()
isRootDeviceByeByeMessage
protected boolean isRootDeviceByeByeMessage()
Copyright © 2010 Teleal GmbH, Switzerland. All Rights Reserved.