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

[Tuomo Penttinen]

Hello all,

On Wed, March 31, 2010 10:54 am, Bart Cerneels wrote:
> 2010/3/30 Kevin Ottens <ervin at kde.org>:
>> On Sunday 21 March 2010 16:15:46 Nikhil Marathe wrote:
>>> I would really love to participate in GSoC and get KDE to have
>>> seamless UPnP support and allow
>>> Amarok to treat the network as a great collection. I have been working
>>> on understanding the UPnP
>>> stuff and using the Hupnp library and a bit of Coherence for the past
>>> 2-3 weeks, and been in contact
>>> with Bart Cerneels, the prospective mentor. Based on all this, here is
>>> my first draft of the proposal.
>>
>> Very good proposal as other pointed out. And you can tell it from the
>> size of
>> this thread... :-)
>>
>> ... actually I've been wondering where to chip in for a few days
>> already, but
>> just gave up and replying to the thread starter. ;-)
>>
>>> Note about kioslave implementation
>>> ----------------------------------
>>> [...]
>>> Meanwhile having a library like HUpnp will keep the core pretty small.
>>> It provides
>>> the Control Point and device discovery support that is the basic
>>> requirement for now.
>>
>> Note that I see a risk of going for a library without any central cache
>> across
>> process. Each application which will need to list the UPnP devices will
>> trigger yet another discovery on the network uselessly stressing it.
>>
>> If you ditch Coherence or something else similar, you might want to
>> reintroduce a way of caching the list of UPnP devices and serving it to
>> the
>> applications (being it a central daemon or an on disk mmapped cache).
>>
>
> Actually, if the discovery is done by Solid and the result is an
> IP-address of a device that is known to be UPnP compliant (well, at
> least it has a description), then preforming a discovery in the client
> application is unnecessary. Although I should say the network load of
> a broadcast discovery is laughably small. It also serves the purpose
> of checking to see if the device is still active or changed IP without
> solid noticing. So it's more error resistant.

I agree. The UPnP discovery protocol is lightweight enough that I wouldn't
worry about it in most environments. 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.

> Tuomo, HUPnP author, should chime in here: Is the discovery optional
> or can HControlPoint be changed to skip discovery?

Currently the HControlPoint always performs discovery (ssdp:all) when it
is initialized. However, it is very easy to make it configurable, which I
think is a good feature to add anyway. Thanks for the idea. You can
consider it done. :-)

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.

Regards,

Tuomo