Classes

# Ssdp
[HUPnP Core]

This page provides information about the HUPnP's classes that provide the SSDP functionality required for the discovery phase of the UPnP Device Architecture. More...

## Classes
class | HResourceAvailable
| A class that represents the resource available (ssdp:alive) message. More...
class | HResourceUnavailable
| Class that represents the device unavailable (ssdp:byebye) message. More...
class | HResourceUpdate
| Class representing the device update (ssdp:update) message. More...
class | HDiscoveryRequest
| Class representing an M-SEARCH (ssdp:discover) message. More...
class | HDiscoveryResponse
| A class that represents a response to a HDiscoveryRequest. More...
class | HSsdp
| This class is used for sending and receiving SSDP messages defined by the UPnP Device Architecture specification. More...

## Detailed Description

According to the UPnP Device Architecture specification version 1.1, When a device is added to the network, the UPnP discovery protocol allows that device to advertise its services to control points on the network. Similarly, when a control point is added to the network, the UPnP discovery protocol allows that control point to search for devices of interest on the network (p. 19).

The mentioned discovery protocol is SSDP and it is about exchanging HTTP messages over UDP.

Note:
  As mentioned in the Herqq::Upnp::HSsdp, these classes implement the SSDP as it is required by the UDA specification. The IETF SSDP draft is not implemented in full.

To send or receive SSDP messages, you need to use Herqq::Upnp::HSsdp class. You can either derive from it or use it directly. In either case, sending messages is straightforward:

     Herqq::Upnp::HSsdp ssdp;

     Herqq::Upnp::HResourceAvailable deviceAvailable(
           1800, // how long the advertisement is valid in seconds
           QUrl("127.0.0.1:1900/mydevice"), // where the device description can be downloaded
           Herqq::Upnp::HProductTokens("unix/5.1 UPnP/1.1 MyProduct/1.0"), // some information about the host and product
           Herqq::Upnp::HDiscoveryType("uuid:5d724fc2-5c5e-4760-a123-f04a9136b300::upnp:rootdevice")); // universally unique identifier

     ssdp.announcePresence(deviceAvailable);

The above example sends a single ssdp:alive message indicating that a UPnP root device is now available.

Note:
  All SSDP classes validate the provided information during object construction. For instance, if the argument to the Herqq::Upnp::HDiscoveryType is invalid, the constructed object will be invalid as well, e.g Herqq::Upnp::HDiscoveryType::isValid() returns false. In such a case, the creation of Herqq::Upnp::HResourceAvailable will fail and consequenlty, the `HSsdp` will not send anything.

Receiving messages is almost as simple. You can use the class directly in which case you have to connect to the exposed signals. For instance, to receive signals when resource available messages are received, you should do:

     MyClass::MyClass(QObject* parent) :
         QObject(parent), m_ssdp(new Herqq::Upnp::HSsdp())
     {
         connect(
             m_ssdp, SIGNAL(resourceAvailableReceived(Herqq::Upnp::HResourceAvailable)),
             this  , SLOT  (resourceAvailableReceived(Herqq::Upnp::HResourceAvailable)));
     }

     MyClass::resourceAvailableReceived(const Herqq::Upnp::HResourceAvailable&)
     {
         // do something
     }

Note the used signature with the SIGNAL and SLOT macros. You can also derive from `HSsdp` in which case you can override the various `protected` `virtual` methods that will be called upon message reception.

Attention:
  Usually you have no need to use the classes in this module directly. These classes may be useful in case you are writing your own device host or control point. Otherwise, the Herqq::Upnp::HControlPoint and Herqq::Upnp::HDeviceHost classes may suit your needs better.