Monday April 25th Milestone Goal

  1. Project 0-like app, running on phone.

Wednesday May 4th Milestone Goal

The demo should consist of a remotely controllable light. For the purpose of this demo the light will be a mockup. The light will be on the same machine that HomeOS is running on, and will be visible remotely through a USB webcam.

  1. Get light-switch controller running on the windows phone and communicating with HomeOS while on the same network.
  2. Create the light application that will act as a controllable light.
  3. Create a driver for the light app that will allow it to be controlled by a multi level switch.
  4. Set up webcam to observe any change in the mock-light's behaviour.
  5. Make switching the light possible from outside the LAN.
  6. Make switch externally accessible without changing router (optional given time)

Wednesday May 25th Milestone Goal

This demo should appear very similar to the previous demo. Dynamic DNS is enabled and HomeOS will be contacted using this human readable address rather than a dotted-quad. It wasn't until Tuesday night before the milestone that I discovered my NAT traversal wasn't going to work, so I will most likely not have the relay server operational for this milestone.

  1. Have a human readable URL for HomeOS on my machine using Dynamic DNS.
  2. Implement a STUN server for HomeOS.
  3. Implement a relay server that allows communication despite NATs and firewalls.

HomeOS Webcam

Dynamic DNS

Dynamic DNS has the ability to solve the problem of a user being assigned a public IP by their ISP that is not static. A well known provider of this service is DynDNS. The way it works is:

  1. The client registers an IP and domain name with DynDNS.
  2. The client network senses that its IP address has changed.
  3. The new IP is sent to the DynDNS server.
  4. The new IP is paired with the clients domain name by the DynDNS server.

This takes care of the problem of a changing public IP address on a network, but unfortunately does nothing to help with NAT. This can also be used by a cell phone, but in this case it might not be as useful since you will often be on a network where you don't have control of port forwarding.

STUN Server

A STUN Server has the ability to enable NAT traversal with some routers. To test the feasibility of this as a solution for my router I implemented a simple STUN Server, a dummy HomeOS, and a test client.

The various pieces interacted in the following manner:

  1. The STUN server ran outside of a NAT, on an Attu machine, and listened for requests from the dummy HomeOS and the client.
  2. Dummy HomeOS would send its LAN side address and port to the server at regular time intervals.
  3. The server extracted the LAN address from the message body, and the WAN address from the socket connection.
  4. Both connections would be tried, with the first successful one being used (this part was not implemented yet, since I wanted to ascertain the functionality of connecting from the outside first).
  5. The client would connect to the server, ask for the addresses, and try connecting to the dummy HomeOS (using the WAN address for the purpose of my initial testing).

Unfortunately (or perhaps fortunately for security's sake), my router's firewall considered a reply coming from someone other than the recipient of the initial message to be an attack. Because of this, even if the NAT traversal was successful, the router would still require modification to bypass the firewall. As such, and because of time limitations, I am abandoning this approach in favor of a relay server.


HomeOS and WP7 communicate over HTTP which is layered above TCP. Punching a hole in the NAT using UDP is supposed to be fairly effective and reliable; however, it is much less reliable over a TCP connection. Often this depends on the router and how "well behaved" it is. Switching the communications to use UDP does not seem to be an option, since WP7 does not yet support socket connections. Furthermore, this would require an extensive reworking of the existing structure.

At this point the most reasonable options seem to be:

For any of the more complex methods it seems that using the cloud relay service would be a good fallback method. Because of this I will attempt to implement the relay method first. I can then try and improve performance using another method.

Risk Mitigation

Using a relay server for all communication between HomeOS and WP7 is probably the most straightforward and easy to implement. I will use this method first and expand on it given time. This should ensure a working product even if I lack sufficient time to implement a more sophisticated method.

Equipment out