[Kde-hardware-devel] [GSoC] Preliminary UPnP support proposal

[Friedrich W. H. Kossebau]

Hi all (and Tuomo),

Mardi, le 6 avril 2010, à 23:41, Kevin Ottens a écrit:
> On Wednesday 31 March 2010 14:42:03 Tuomo Penttinen wrote:
> > I agree. The UPnP discovery protocol is lightweight enough that I
> > wouldn't worry about it in most environments.

Emphasis on _most_ environments ;)

> Actually I like numbers. :-)
> 
> My worry lies in the fact that we're going for the full game of having it
> in libsolid, which means that such a discovery will be triggered by any
> apps which starts and ask for a StorageAccess (which means at least
> anything which spawns a file dialog).

And slightly worse. Any SSDP message coming in will wake up all of the 
processes which listen for these, just to find out if it is interesting to 
them or not. Minor case, but still burns ressources (think of mobile uses) and 
should be avoided as a standard pattern.

Though HAL/Solid isn't any better here, both also don't offer any kind of 
active search/query (cmp. view in database), if I looked correctly 
(DeviceNotifier reports simply about all devices), so wake up all of the 
processes.

Still no numbers. And these might be small. But all those small numbers add up 
:)

> > In my opinion, even the description
> > phase doesn't add that much of network load that I'd want to pay the
> > price of added complexity, which the inter-process caching solution
> > introduces.
> 
> Fair enough, let's avoid premature optimization. And it's all buried in the
> backend anyway so it's not like we're going to break BC later on if we
> introduce complexity for the optimizations.

If it is just for the discovery stuff this isn't too much a complexity IMHO.

Still now is the time to collect some use-cases how we approach the UPnP 
world. There could be the danger we wrap around the UPnP spec instead of 
making use of it for our needs.

Currently KDE software basically will be a client to services from UPnP 
devices (being control point in UPnP terms). So if there is a convenience lib 
one should be just for client stuff IMHO. Server stuff should be handled by a 
different lib. I suppose that code for server stuff is larger and would just 
be unneeded payload for most applications (also in disk size).
(not sure how the P2P situation with mobile devices proves me wrong here)

We also wouldn't put http server stuff into the http access lib, would we?

Doing the discovery in a proxy/cache not only avoids work duplication 
(increase of resource needs per process), it has also the advantage to be 
faster (cache). And it is done for other discovery systems, too: There is 
Avahi for DNS-SD, as a central small proxy process (our code layer to it is 
KDNSSD).

The interaction with the individual server types (UPnP devices) might ideally 
be implemented by dedicated libs/modules which itself make use of another 
convenience lib/module, as the base protocol/communication is the same (UPnP 
specs + SOAP). This could be HUPnP (or Coherence via D-Bus). The MediaServerX 
types are ideally proxied by an kio-slave, we all agree here :)

Haven't yet thought about implementation of UPnP devices (like offering media 
collections as a UPnP MediaServerX or the computer as a MediaRenderer), not in 
my interest currently :) 

> > By the way, if any of you have ideas or feature requests for HUPnP, or
> > feedback in general, this is a good chance to influence the development
> > before the API & ABI is locked for the first major release. I'd
> > appreciate your comments.

Would like to give you some more comments, but please accept my limited time 
and find my ideas/thoughts in these emails :)

> Friedrich is working on the UPnP backend, currently it is based on
> Coherence but I seem to remember he wasn't necessarily willing to keep it
> that way. So I guess he'll be interested in taking a look at HUPnP...

Just looking at the number of Coherence in System Activity tells me Coherence 
is improvable (10,7 MiB unshared), but I haven't yet talked to the Coherence 
developers to find out how much this can be improved (well, the usage of 
Python and Twisted might hint there is not too much to gain.)

So I took some experimental stand-alone code I had written before (sending M-
Search messages and parsing search answers/notifications) and hacked together 
a little SSDP proxy/cache named Cagibi: 

http://websvn.kde.org/trunk/playground/network/cagibi/

It's read-only, so doesn't support publishing. System Activity shows 424 kiB 
unshared, so there would be some gain compared to Coherence just for the SSDP 
cache usage (avahi-daemon is at 176 kiB, though, Qt is cute and easy but not 
the smallest). And doesn't offer live queries, neither, just sends signals 
about each device change. Also is currently on the session bus, not the system 
one (due to my development system setup).

It basically works now, my (local) experimental Solid UPnP backend based on it 
seems fine, including timeouts for caching and byebyes.

I am going to port the network:/ kio-slave next, to enhance the D-Bus 
interface which is currently only designed by the Solid use-case. Once that 
port is done I will propose to use Cagibi instead of Coherence as an SSDP 
cache. Later on it might be nice to find a XDG spec for the D-Bus interface, 
so the actual implementation doesn't matter (there is also that GUPnP stuff 
which I haven't yet looked at).
Ping me if you want the Solid patch now.

Cheers
Friedrich
-- 
KDE Okteta - a simple hex editor - http://utils.kde.org/projects/okteta