9

Proposal:
One of the big facilities missing from KDE is UPnP Gateway control. UPnP Gateways allow apps on client PCs to dynamically create port forward rules required to support capabilities such as webcam, file transfer, VoIP and other services.

Without this capability it is necessary to create and administer permanent port-forwarding rules in firewalls. This is not only a security risk, but it also beyond the capabilities of many beginner users. To these user these applications simply "do not work".

Note that a couple of KDE applications like ktorrent have implemented some local UPnP capability, but this is on a point basis and this does not benefit other apps, like Kopete, which would greatly benefit from UPnP but currently do not support it.

UPnP Gateway (IGD) is supported on most consumer firewall/router devices including many Linux/BSD based ones. It is acknowledged that this is probably not desirable for a corporate environment, but it is entirely optional for those who do not wish to use it.

Solution:
The proposed solution takes the form of two capabilities:

1. A UPnP Gateway control daemon within KDE which discovers local UPnP gateways and communicates with them. This will also track requests from client applications and create appropriate requests for port forwarding on the gateway device. This may also implement some form of access control security, and could also monitor gateway statistics. Client applications communicate with the daemon over DBus.

2. A GUI application which could sit in the system tray. This communicates with the daemon to provide configuration and control. This could, for instance, show all active connections, statistics, allow connections to be forced down, etc.

As stated, client applications would not need to implement any UPnP themselves. They could simply pass a request to the daemon for any port forwarding they require using a relatively simple DBus call..

It is also noted that the standard Qt network library may not support the capabilities required to build UPnP services in a platform-independent way. It is likely that a separate UPnP library will be required for this (Cybergarage do a nice C++ one). Even if this is not totally platform independent, the loose coupling between the applications and the daemon mean that this capability is entirely optional. If KDE is being run in corporate environment where UPnP is inappropriate, the daemon can be disabled (one assumes any UPnP on a gateway device will also be disabled). If KDE is ported to a platform where the daemon does not immediately work, it can be left out until a platform-specific version of the daemon can be developed.

Cheers,

Keith