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

[Bart Cerneels]

On Tue, Mar 30, 2010 at 14:01, Armijn Hemel <armijn at uulug.nl> wrote:
> hi!
>
>> It's unlikely that we will require much more than what Hupnp already
>> provides, which is a control point, service discovery and action
>> invocation mechanisms.
>
> I would not say that right away. Although UPnP does seem simple at first
> sight there is quite a bit more to it when you want to go for a full
> implementation and Coherence is much much better at this right now.
>
> One thing is that there are many incredibly dumb UPnP implementations
> out there that don't parse the XML that is used in the protocol, but do
> simple string comparisons. If the XML does not match with what Windows
> XP sends (namespaces and all that) you are out of luck. I encountered
> this problem with many VxWorks based machines, like the Linksys WRT54Gv5
> and later.

That is not relevant for this project. We are working with
MediaServers which, thanks to DLNA, have become very standardized and
predictable. Also these implementations certainly don't run on
crippled RTOS'es.

>
> There is also the fact that you might want to send received device
> announcements to many programs at once, especially in a multiseat
> desktop. I am not sure how well that can be done with Qt and slots, to
> have one system wide daemon running and sending signals to multiple
> programs of multiple users at once.

The only limiting factor there can be the broadcast address+port used
by UPnP (239.255.255.250:1900) will be reserved. Unless some IPC
system is limits the simultaneous use of 2 UPnP clients. The rest of
the stack runs independent, with some redundant work being done,
although extremely minimal.

>
> Another thing that you are currently overlooking is eventing (HTTP
> callbacks and all that). I must admit, this is hardly ever used, but it
> adds a lot of complexity if you want to make a complete UPnP
> implementation. One option would be to ignore eventing completely ;-)

It's the basis of UPnP, so any upnp-stack worth that name implements
it. So does HUPnP.

>
>> But Hupnp does remain something to watch out for, especially if it
>> stabilises and development is steady. A C++ lib using Qt signals and
>> slots is IMHO much nicer than talking over D-BUS :)
>
> See above, I'm not entirely sure it is.
>
> Now, some completely (not entirely unrelated) unrelated things.
>
> In real life I have encountered only a few profiles. Internet Gateway
> Device is of course still a very important one. Right now there are a
> few client implementations in KDE. From the top of my head, I think some
> work was done in Kopete and Ktorrent, but both implementations were
> quite barebones.
>
> MediaServer and MediaPlayer are quite common these days. I would advise
> against implementing MediaPlayer in Amarok, unless you want people to be
> able to remotely control your Amarok (I would not want that). Supporting
> MediaServer is a very obvious thing to do. Everyone would love that. The
> hardest part (I think) would be to get searching right. There are
> various flavours: 1.0 and 2.0. If you want to go for DLNA stick with
> 1.0.

Regardless of personal preference, there is very serious interest for
that in our userbase. Important to note is that a good implementation
of DMR (the DLNA name for UPnP MediaRender) will request user
permission before being controlled.

We could even consider implementing the Microsoft extensions used by
WMP11 to permit access to shared data, which is quite sane in my
opinion.

There currently is no plan to implement any of this though.

>
> A protocol I am seeing sometimes is the new WPA2 setup stuff as pushed
> by the WifiAlliance, where the exchange for WPA2 keys is done via UPnP,
> if the machine and router are connected via wires.

This is called WPS. Keys are exchanged using a pin code technique are
a button press. If NetworkManager could implement this live would get
a whole lot simpler for my sister in law, that uses my old laptop
running KDE SC 4 :)

>
> Another UPnP implementation that I sometimes encounter is RemoteUI.
> Controlling it would be fun, but it is not installed on my devices.
>
> What I've heard is that the HVAC-profile is actually in use, but I have
> never encountered those IRL (I guess HVACs are also more of an American
> thing).

Some proposed protocols are just that, proposals. These for instance
don't have an implementation or there is just no interest.
In general, if it's not covered by DLNA don't seriously consider
implementing it. it just happens that some remote UI use cases are
covered in the latest DLNA requirements (August 2009) though. So we
might start seeing this pop up.

There are also printing scenarios in DLNA, perhaps we should support
those as well, or by proxy via CUPS. Probably a bit harder since KDE
doesn't have it's own printing system anymore.

>
> As others said: integrating control point functionality into Amarok for
> just MediaServer should already be more than enough of a challenge ;-)
>
> armijn
>

Indeed, but the future is promising :)