Wednesday, August 11, 2010

Google Summer of Code Update - Bridging UPnP networks

The UPnP eventing is now supported! As I mentioned in the last two updates that we had two main use cases to support - NAT (map a port at which internal UPnP device is running on) or to run an HTTP proxy at the router itself for each local device (if access is available) where the proxy acts as a fake device and routes all the data between the internal device and a remote Control Point.

I integrated both the approaches as that would make it possible to support any of the two use cases easily through some simple configuration. Here's the picture -



HTTPBridge (HTTPSecureBridge) is a two way proxy (two servers and a session) to control flow of data between local Device/ControlPoint and a remote ControlPoint/Device. It has two ends - one 'internal_server' which communicates with local entities and the other 'external_server' which communicates with foreign entities. External_server address is mapped at the router, integrating both the NAT and proxy approaches.

1. LocalControlPoint (LCP) is a class which keeps information about local UPnP devices.

2. Upon receiving a notification about a new local UPnP device, LocalControlPoint starts up a new HTTPSecureBridge. The bridge maps the address of the 'external_server' at the router using GUPnP-IGD and maintains a state that all the data arriving at the external_server will be forwarded to the actual device.

3. When the external_server's address has been mapped, it is notified to the ExternalContext that there's a device at this address.

Now at a foreign home -

4. RemoteControlPoint calls the discovery handler at ExternalContext and also subscribes for future events. It initially retrieves information about remote UPnP devices in an XML file. RemoteControlPoint also has to map a port to make itself reachable for remote clients.

5. Now when a RemoteControlPoint has subscribed itself at an ExternalContext, for each local UPnP event, the ExternalContext provides as much information to the RemoteControlPoint as GSSDP provides to GUPnP ControlPoint. For a new device at the remote home, a new HTTPSecureBridge is started with a state that all data arriving at the 'internal_server' will be forwarded at the remote device address (which actually is a HTTPSecureBridge at the other end).

6. A new ServiceProxy and DeviceProxy is created with a fake device address as the internal_server address of the bridge and the client is notified about the event.

As we've been planning to support the security through X.509 certificates, that will be easily handled while creating new HTTPBridges through Libsoup.

1 comment:

  1. Interesting solution! Do you have any ongoing activities or future plans with this?

    ReplyDelete