Does ohnet support Embedded devices?

[simonc]

That sequence of actions (create a device, advertise it on the network, wait, delete device) should be supported. It also works in local tests for me.

Can you post a full example app that demonstrates the failure and that I'll be able to run please?

[SiMet]

I attached zip where is Xcode project.

All you need to make it compile is add libohNet.a to /libs/ohnet/lib/ for architecture which you'd like to run.

On my computer I've lib for x86, armv7 and arm64 but it's 80MB


I hope this code will help you.

[simonc]

Thanks. Looking at the code, I think I see the issue.

Calling device->AddDevice(device1); passes ownership of device1 to device.
This means that delete device; will also delete device1.

So, your test should work if you remove the line delete device1;.

(As a general rule, most of our C++ APIs that pass objects by pointer are transferring ownership. If we only want to allow objA to access objB, we normally pass objB by reference.)

[SiMet]

You're right. That's solve my problem.
Lesson from my situation is that when I'm tired I should go home and not debug code.
I made lots of mistakes which hide me solution.

Thank you for clarify this.

[SiMet]

So question from Control Point side.

I made:
root device with two embedded devices. (one of them has ContentDirectory service)

Then I'm tring to discover them:
CpDeviceListCppUpnpAll return me only root device
CpDeviceListCppUpnpServiceType("schemas-upnp-org","ContentDirectory",1,..,..) doesn't discover any Device.

I had also made test for ServiceType with Intel Tools.

I started my Control Point with

Code:

CpDeviceListCppUpnpServiceType("schemas-upnp-org", "ContentDirectory", 1, MakeFunctorCpDeviceCpp(*this,&MyClass::DeviceFound),MakeFunctorCpDeviceCpp(*this,&MyClass::DeviceLost));

Then started AV Media Server.

In wireshark I see ALIVE on start:

Code:

NOTIFY * HTTP/1.1
NT: urn:schemas-upnp-org:service:ContentDirectory:1
CACHE-CONTROL: max-age=1800
HOST: 239.255.255.250:1900
NTS: ssdp:alive
USN: uuid:8bd93037-d5d6-4985-9b3a-6b005ea1e277::urn:schemas-upnp-org:service:ContentDirectory:1
SERVER: Windows NT/5.0, UPnP/1.0
LOCATION: http://192.168.1.6:51674/
Content-Length: 0

however Control Point doesn't get know that new device appeared in network.

Using CpDeviceListCppUpnpAll DeviceFound method is called when Media Server appears on network.


In this post I have few questions:
1) Does Embedded devices should be also discovered?
2) How to get embedded devices when I discovered root device?
3) Does CpDeviceListCppUpnpServiceType works well (In wireshark I noticed M-Search which looks good)
4) How to fetch list of services from CpDeviceCpp ?

[simonc]

Embedded devices and their services should be discovered. TestDviDiscovery attempts to confirm this.

Can you show how you're setting up the devices in your test please?

[SiMet]

(26-06-2015 04:15 PM)simonc Wrote:  Embedded devices and their services should be discovered. TestDviDiscovery attempts to confirm this.

Can you show how you're setting up the devices in your test please?

Embedded devices are discovered but not by ohNet control point stack.

Code:

#include <stdio.h>
#include <OpenHome/Net/Cpp/OhNet.h>
#include <OpenHome/Net/Cpp/DvDevice.h>
#include <OpenHome/Net/Cpp/CpDeviceUpnp.h>
#include "CpListener.h"

using namespace OpenHome;
using namespace OpenHome::Net;

NSString *const kDvDeviceUUID = @"UUID";
NSString *const kDvDeviceUpnpDomain = @"Upnp.Domain";
NSString *const kDvDeviceUpnpType = @"Upnp.Type";
NSString *const kDvDeviceUpnpVersion = @"Upnp.Version";
NSString *const kDvDeviceUpnpFriendlyName = @"Upnp.FriendlyName";
NSString *const kDvDeviceUpnpManufacturer = @"Upnp.Manufacturer";
NSString *const kDvDeviceUpnpModelName = @"Upnp.ModelName";

class Logger{
public:
    inline Logger(){};
    void inline Log(const char* aMsg){NSLog(@"> %s",aMsg);}
};

class CpListener{
public:
    CpListener(std::string _name);
    void DeviceFound(OpenHome::Net::CpDeviceCpp &_device);
    void DeviceLost(OpenHome::Net::CpDeviceCpp &_device);
private:
    std::string name;
};
@interface ViewController (){
    OpenHome::Net::DvDeviceStdStandard* device1;
    OpenHome::Net::DvDeviceStdStandard* device2;
    OpenHome::Net::CpDeviceListCpp* list;
    CpListener* listener;
    Logger logger;
}
@end

@implementation ViewController

-(void) viewDidAppear:(BOOL)animated{
    [super viewDidAppear:animated];

    OpenHome::Net::InitialisationParams* initParams =  OpenHome::Net::InitialisationParams::Create();
    initParams->SetDvMaxUpdateTime(30);
    initParams->SetLogOutput(MakeFunctorMsg(logger,&Logger::Log));
    OpenHome::Net::UpnpLibrary::Initialise(initParams);
    
    std::vector<NetworkAdapter*>* subnets = OpenHome::Net::UpnpLibrary::CreateNetworkAdapterList();
    
    OpenHome::Net::UpnpLibrary::StartCombined(subnets->back()->Subnet());

    NSString* uuid1 = [[NSUUID UUID] UUIDString];
    NSString* uuid2 = [[NSUUID UUID] UUIDString];
    const std::string suuid1([uuid1 UTF8String]);
    device1 = new OpenHome::Net::DvDeviceStdStandard(suuid1);
    device2 = new OpenHome::Net::DvDeviceStdStandard([uuid2 UTF8String]);
    
    NSLog(@"Device 1 %@",uuid1);
    device1->SetAttribute([kDvDeviceUpnpDomain UTF8String], [@"1" UTF8String]);
    device1->SetAttribute([kDvDeviceUpnpType UTF8String], [@"1" UTF8String]);
    device1->SetAttribute([kDvDeviceUpnpVersion UTF8String], [@"1" UTF8String]);
    device1->SetAttribute([kDvDeviceUpnpFriendlyName UTF8String], [@"1" UTF8String]);
    device1->SetAttribute([kDvDeviceUpnpManufacturer UTF8String], [@"1" UTF8String]);
    device1->SetAttribute([kDvDeviceUpnpModelName UTF8String], [@"1" UTF8String]);
    
    NSLog(@"Device 2 %@",uuid2);
    device2->SetAttribute([kDvDeviceUpnpDomain UTF8String], [@"2" UTF8String]);
    device2->SetAttribute([kDvDeviceUpnpType UTF8String], [@"2" UTF8String]);
    device2->SetAttribute([kDvDeviceUpnpVersion UTF8String], [@"2" UTF8String]);
    device2->SetAttribute([kDvDeviceUpnpFriendlyName UTF8String], [@"2" UTF8String]);
    device2->SetAttribute([kDvDeviceUpnpManufacturer UTF8String], [@"2" UTF8String]);
    device2->SetAttribute([kDvDeviceUpnpModelName UTF8String], [@"2" UTF8String]);
    
    device1->AddDevice(device2);
    device1->SetEnabled();
    device2->SetEnabled();
    
    listener = new CpListener([@"All" UTF8String]);
    list = new CpDeviceListCppUpnpAll(MakeFunctorCpDeviceCpp(*listener,&CpListener::DeviceFound),MakeFunctorCpDeviceCpp(*listener,&CpListener::DeviceLost));
        
}
@end

CpListener::CpListener(std::string _name) : name(_name){}
void CpListener::DeviceFound(OpenHome::Net::CpDeviceCpp &_device){
    NSLog(@"Found %s %s",name.c_str(),_device.Udn().c_str());
}
void CpListener::DeviceLost(OpenHome::Net::CpDeviceCpp &_device){
    NSLog(@"Lost %s %s",name.c_str(),_device.Udn().c_str());
}

Output after run this code is:

Code:

2015-06-30 09:37:22.304 ohnetTest[9125:835697] Device 1 DEA6FC4C-181D-48F8-A22E-032DE4EE583B
2015-06-30 09:37:22.305 ohnetTest[9125:835697] Device 2 0BD5CC00-60C1-481B-BE40-F64342E8C8B7
2015-06-30 09:37:22.341 ohnetTest[9125:835754] Found All DEA6FC4C-181D-48F8-A22E-032DE4EE583B

Is is bug or expected behaviour?
If it's expected how can I get instance of embedded CpDevice?


Next interesting behaviour I noticed is when I set device2 enabled or not.

When device2 is not enabled I can see it in deviceSpy but cannot detect by new CpDeviceListCppUpnpDeviceType("2","2",1,MakeFunctorCpDeviceCpp(*listener,&CpListener::DeviceFound),MakeFunctorCpDeviceCpp(*listener,&CpListener::DeviceLost));

when device2 is enabled I see it in DeviceSpy and could discover it with above method.

And next interesting bug:

when I changed @"Upnp.Domain" to "schemas-upnp-org" and try discover with deviceType new CpDeviceListCppUpnpDeviceType("schemas-upnp-org","2",2... I don't discover device.
Change to schemas_upnp_org makes that device is discovered again.
Why this dash is so magical?

[simonc]

(30-06-2015 07:43 AM)SiMet Wrote:  Embedded devices are discovered but not by ohNet control point stack.
[snip]
Is is bug or expected behaviour?
If it's expected how can I get instance of embedded CpDevice?

This is not expected behaviour. It's also behaviour I can't reproduce.

See ohNet's test file TestDviDiscovery.cpp for an example of a control point that manages to discover embedded devices. I suggest you use this as a template to update your code.

(30-06-2015 07:43 AM)SiMet Wrote:  Next interesting behaviour I noticed is when I set device2 enabled or not.

When device2 is not enabled I can see it in deviceSpy but cannot detect by new CpDeviceListCppUpnpDeviceType("2","2",1,MakeFunctorCpDeviceCpp(*listener,&CpListener::DeviceFound),MakeFunctorCpDeviceCpp(*listener,&CpListener::DeviceLost));

when device2 is enabled I see it in DeviceSpy and could discover it with above method.

Do you mean that devices that are disabled are still discoverable? This would be a bug. If a device is not enabled, it should never send out ALIVE announcements and should not respond to MSEARCH requests.

(30-06-2015 07:43 AM)SiMet Wrote:  And next interesting bug:

when I changed @"Upnp.Domain" to "schemas-upnp-org" and try discover with deviceType new CpDeviceListCppUpnpDeviceType("schemas-upnp-org","2",2... I don't discover device.
Change to schemas_upnp_org makes that device is discovered again.
Why this dash is so magical?

You should provide the 'real' domain for device lists, not a UPnP representation. So, for services/devices defined by the UPnP forum, use "upnp.org" as the domain throughout your code.

[SiMet]

(01-07-2015 01:17 PM)simonc Wrote:  

(30-06-2015 07:43 AM)SiMet Wrote:  Embedded devices are discovered but not by ohNet control point stack.
[snip]
Is is bug or expected behaviour?
If it's expected how can I get instance of embedded CpDevice?

This is not expected behaviour. It's also behaviour I can't reproduce.

See ohNet's test file TestDviDiscovery.cpp for an example of a control point that manages to discover embedded devices. I suggest you use this as a template to update your code.

are we talk about this file: TestDviDiscovery?
Here you do not use CpDeviceListCpp and in this class (exactly in CpDeviceListCppUpnpAll) is probably bug.

(01-07-2015 01:17 PM)simonc Wrote:  

(30-06-2015 07:43 AM)SiMet Wrote:  Next interesting behaviour I noticed is when I set device2 enabled or not.

When device2 is not enabled I can see it in deviceSpy but cannot detect by new CpDeviceListCppUpnpDeviceType("2","2",1,MakeFunctorCpDeviceCpp(*listener,&CpListener::DeviceFound),MakeFunctorCpDeviceCpp(*listener,&CpListener::DeviceLost));

when device2 is enabled I see it in DeviceSpy and could discover it with above method.

Do you mean that devices that are disabled are still discoverable? This would be a bug. If a device is not enabled, it should never send out ALIVE announcements and should not respond to MSEARCH requests.

This device doesn't send ALIVE and not respond to M-Search. However, It's still visible in device description. I'm not sure (my friend also) if it's bug from according to upnp specs.

(01-07-2015 01:17 PM)simonc Wrote:  

(30-06-2015 07:43 AM)SiMet Wrote:  And next interesting bug:

when I changed @"Upnp.Domain" to "schemas-upnp-org" and try discover with deviceType new CpDeviceListCppUpnpDeviceType("schemas-upnp-org","2",2... I don't discover device.
Change to schemas_upnp_org makes that device is discovered again.
Why this dash is so magical?

You should provide the 'real' domain for device lists, not a UPnP representation. So, for services/devices defined by the UPnP forum, use "upnp.org" as the domain throughout your code.

Here I could not agree with you. Upnp specify in their documents (for example http://upnp.org/specs/av/UPnP-av-Content...ervice.pdf or http://upnp.org/specs/av/UPnP-av-MediaSe...evice.pdf) that ContentDirectory service have serviceType: "urn:schemas-upnp-org:service:ContentDirectory:1" and MediaServer deviceType is "urn:schemas-upnp-org:device:MediaServer:1".
If I'd like make valid MediaServer with ContentDirectory which pass UCTT tests. This types have to be as above and it's my scenario.

[simonc]

(02-07-2015 01:19 PM)SiMet Wrote:  are we talk about this file: TestDviDiscovery?
Here you do not use CpDeviceListCpp and in this class (exactly in CpDeviceListCppUpnpAll) is probably bug.

Yes, that's the file.

The amount of code in CpDeviceListCpp and CpDeviceListCppUpnpAll is very small. The latter is just a thin wrapper around CpiDeviceListUpnpAll which is used by TestDviDiscovery. It seems very unlikely that the bug is in the C++ bindings. They contain very little code and don't do anything to check for embedded devices.

I still think a subtle bug in your test code is the most likely cause of problems.

(02-07-2015 01:19 PM)SiMet Wrote:  This device doesn't send ALIVE and not respond to M-Search. However, It's still visible in device description. I'm not sure (my friend also) if it's bug from according to upnp specs.

Thanks, I understand now.

This behaviour isn't deliberate. It is a bug but is hopefully a very minor bug. Well-behaved control points will always start with a MSEARCH. If there is no response to this, they'll have no reason to try a GET for device xml.

I've raised a bug about this. Given that it would only cause problems for poorly written control points, it may take a while before we fix it.

(02-07-2015 01:19 PM)SiMet Wrote:  

(01-07-2015 01:17 PM)simonc Wrote:  You should provide the 'real' domain for device lists, not a UPnP representation. So, for services/devices defined by the UPnP forum, use "upnp.org" as the domain throughout your code.

Here I could not agree with you. Upnp specify in their documents (for example http://upnp.org/specs/av/UPnP-av-Content...ervice.pdf or http://upnp.org/specs/av/UPnP-av-MediaSe...evice.pdf) that ContentDirectory service have serviceType: "urn:schemas-upnp-org:service:ContentDirectory:1" and MediaServer deviceType is "urn:schemas-upnp-org:device:MediaServer:1".
If I'd like make valid MediaServer with ContentDirectory which pass UCTT tests. This types have to be as above and it's my scenario.

I agree that we need to send "schemas-upnp-org" over the wire. You shouldn't specify this when calling device lists however. If you specify "upnp.org" as the domain of a device list, it'll convert this as required for network requests.