Overview | Package | Class | Use | Tree | Deprecated | Index | Help
PREV CLASS NEXT CLASS | FRAMES NO FRAMES
SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD

## org.fourthline.cling.protocol.async
Class ReceivingNotification

    java.lang.Object
      org.fourthline.cling.protocol.ReceivingAsync<IncomingNotificationRequest>
          org.fourthline.cling.protocol.async.ReceivingNotification

All Implemented Interfaces:
  Runnable

    public class ReceivingNotification

extends ReceivingAsync<IncomingNotificationRequest>

Handles reception of notification messages.

First, the UDN is created from the received message.

If an ALIVE message has been received, a new background process will be started running `RetrieveRemoteDescriptors`.

If a BYEBYE message has been received, the device will be removed from the registry directly.

The following was added to the UDA 1.1 spec (in 1.3), clarifying the handling of messages:

"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."

Of course, they contradict this a little later:

"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. In other words: There is no reason at all why SSDP sends dozens of messages for all embedded devices and services. The composite is the root device and the composite defines the lifecycle of all.

Author:
  Christian Bauer

Constructor Summary
`ReceivingNotification(UpnpService upnpService, IncomingDatagramMessage<UpnpRequest> inputMessage)`

Method Summary
`protected void` | `execute()`

Methods inherited from class org.fourthline.cling.protocol.ReceivingAsync
`getFirstHeader, getInputMessage, getUpnpService, run, toString, waitBeforeExecution`

Methods inherited from class java.lang.Object
`clone, equals, finalize, getClass, hashCode, notify, notifyAll, wait, wait, wait`

Constructor Detail

### ReceivingNotification

    public ReceivingNotification(UpnpService upnpService,
                                 IncomingDatagramMessage<UpnpRequest> inputMessage)

Method Detail

### execute

    protected void execute()

  Specified by:
    `execute` in class `ReceivingAsync<IncomingNotificationRequest>`

Overview | Package | Class | Use | Tree | Deprecated | Index | Help
PREV CLASS NEXT CLASS | FRAMES NO FRAMES
SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD

Copyright © 2013 4th Line GmbH, Switzerland. All Rights Reserved.