Week 1
Week 2
Week 3
Week 4
Week 5-6
Week 7
Week 8
Week 9-11
Week 12
Week 13-14
Week 15-19
Week 20-21
Set up UPnP network and remade the first basic tests. Sniffed network traffic. Conclusions: we have seen M-search messages, alive and bye bye messages. After a discovery has been made by M-search the controlpoint will use a TCP connection to retrieve data about the service. The data is in XML form.
Issue: This might be a problem in several ways. The proxy might be able to answer discovery messages, but should it also be able to set up a TCP connection? If not the sleeping device might need some wake up time before it can establish a TCP connection. This has to be considered. Discussed connection splicing, but this I probably too complex to be implemented.
The big issue is whether we should modify SSDP or not. Probably we will have to because it seems very hard to implement a “silent” proxy that uses the current SSDP version. What modifications will have to be made? What consequences will these changes bring? We talked about at least making some kind of “going to sleep, please take over” message.
Other issues: How should a proxy be chosen? A lot of methods available but on what premises should the decision be made? Can all device act as proxy? Ken suggested looking at Zigbee. Also, do not forget that proxy will have to keep sending out alive messages to make sure that services are not deleted from caches.
Basically this first week has been very chaotic and a lot of time has been spent on paperwork and administrative stuff (getting a car). Have read some articles and found a lot more to read.
Finished reading articles. Articles mainly concerning SSDP, GENA, SOAP, other discovery protocols such as Bluetooth, Jini and Salutation, Zigbee and other low power protocols, TCP splicing and proxying.
Reading has been done to increase our knowledge in UPnP and its protocols. We have also read about other protocols to get inspiration for our solution and to see how the power management problem has been solved in other cases.
Technologies discussed: Master/Slave in Bluetooth (will not fit our network because of Bluetooth’s ad hoc), TCP splicing (will probably not use it because it is to complex to implement), Beacons.
Started to discuss possible solutions for power management in UPnP(See separate list for details). Pros and cons will be considered for each solution and one or two will be selected for prototyping. One will be completely implemented. Note: The solution must be able to wake up on events, not only on discovery. An event starts with a TCP SYN.
Unfortunately we had to spend several hours this week filling out papers and taking care of matters outside of the project (getting our bank accounts, drivers license and meeting with the international office).
Made a list of constraints and objective functions for the solutions we came up with last week. All objective functions we’re prioritized and graded. The invisible proxy and the visible proxy got the highest grading.
We chose to continue developing those two solutions. We started with the invisible proxy. We’ve discussed details in the solution such as when and how messages are going to be sent and the problem with sleeping control points.
A control point has to make a discovery when it wakes up again from sleeping mode, otherwise the information it has about the network will be inaccurate. This might be acceptable since the information will be corrected whenever there’s an SSDP:alive message or the control point receives an error message when trying to use a service. Will forcing the control point to make a discovery mean changing an end device? Probably we can get away by making a configuration. There’s a floating scale between the invisible and visible proxy where more and more changes can be made to the end devices.
We have started to make finite state machines for the solution of the invisible proxy. The service and control point will be basic UPnP functionality while the proxy will be our invention. The FSM:s does not contain eventing yet. We still have to figure out how eventing affects devices. We have read a lot in the UPnP book about SOAP and description. Found out that after each query (e.g. HTTP GET, SOAP Action) the service has 30 seconds to answer. Why 30 seconds and what happens after 30 seconds is still a mystery. We will have to find out.
We have also created the thesis file and made the complete outline with all the headlines. There’s been some discussion about which chapters should be placed in appendix and which should be placed in the introduction.
Completed the FSMs for the invisible proxy solution. Completed FSMs that describe the basic UPnP service and control point. The FSMs are not 100% complete since they lack all error messages that can be sent through HTTP. We have excluded these to make the FSMs more readable. Have also made the FSMs more compact and added comments. Important to remember is that the FSMs are supposed to support the text and not stand alone. Also, “solve the 99% case, not the 100% case”. This is something we will have to remember throughout the project.
We rebuilt our table of design parameters but it is still not satisfactory. We have to fit it into one page and make it more logical. Basically a layout problem. Yet again the table must be explained in the text. We have completely abandoned the original visible proxy solution with changes to SSDP and we are instead focusing on the adding a service solution. The parameter table has been changed according to this and the new solution scored higher.
We have encountered one problem. Control points do not notify any devices in the network of its presence. Therefore the proxy cannot control the control point in the normal sense. Our first assumption was that a CP will only wake up when a user wakes it up. However, the UPnP whitepaper describes an important situation where the CP has to wake up by itself: The CP might be subscribing to a service on the alarm clock in the bedroom and at the same time might be running a script that should turn on the coffeepot in the kitchen when the bedroom alarm sounds. If a CP goes to sleep it will miss the alarm event and therefore not turn on the coffeepot. This means we will have broken important UPnP functionality according to the white paper. The solution for the invisible proxy will simply be to hand the problem over to the application. Whenever there is such a script running the CP cannot be allowed to enter power sleep. With the service implementation the solution is better. We will implement a power sleep service on every CP, and the proxy can therefore handle each CP as it handles any other device. The CP will then be woken when the alarm event arrives.
We also made a simple proof of concept for WOL. So far the program simply broadcasts a UDP packet addressed to FF:FF:FF:FF:FF:FF. The packet contains the Ethernet address of the sleeping device repeated 16 times. The address is hardcoded. We have tried the program and made sure it works.
This week we have done a fair amount of reading about how to implement services in UPnP to prepare for making a proof of concept of that. We have also started writing on chapter one of the theses.
The work during these two weeks mostly consisted of hunting for libraries and trying to understand them. We decided to start the next proof of concept, that is spoofing. To do this we would need a library. The rawstuff (see prof. Christensens tool page) that we modified will probably not work. Biggest problem is that SP2 under Windows XP does not allow raw sockets, which is the key to rawstuff. To go around this we have been looking for libraries with their own DDL’s that will allow us to open sockets in Windows XP. The three main libraries that we tried out were libnet, netwib and winpcap. We spent a lot of time installing and learning important developing tools such as Visual C++ and Dev-C++. We never got libnet to work, even though we spent a lot of time trying to compile and run the programs. We believe that libnet still might have some trouble with the raw socket interface in Windows XP. Winpcap is mainly used for developing sniffers. It provides very powerful sniffing tools. However, the only way to send packets with winpcap is sending packets in hex format through a raw socket. This works even with Win XP, but having to build a complete packet in hex is a lot of work. Therefore we ended up choosing netwib. It provides both sniffing and spoofing tools. It is a very complex library that unfortunately is poorly documented. However we are convinced that it suits our purposes and that we will be able to complete our proofs of concepts using this library. The spoofing proof of concept will not be considered complete until we can make send a spoofed SSDP message that will be accepted by the receiver. We have also started some on our next proof of concept: receiving and answering. This will naturally also be done using netwib.
During these two weeks we constructed our UPnP Power Management homepage that will serve as a presentation of our project. We hope that this homepage will notify other developers and members of the UPnP forum about our project and the progress that we make. The homepage has to be maintained and updated with new material at least once a week.
The goal this week was to finish the spoofing proof of concept and starting with the receive/respond proof of concept. These goals were achieved by digging deeper into the netwib library and getting to know its advantages. We have now managed to send a spoofed SSDP-notify that was sniffed by the device-sniffer from Intel. We have also sent a spoofed M-search that was received and respond to by other UPNP devices. The spoofing proof of concept is now considered done. The next proof of concept, the receive/respond, is almost done to. We have managed to sniff SSDP messages on the network and parse to get all headers and to check what kind of message it is. There still remain some small problems in getting sniffing and spoofing to work together but we expect to have the receive/respond proof of concept complete soon.
This week was spent coding. The receive and respond proof of concept was finished. That means a program that will sniff and M-search packets and answer them with a spoofed HTTP OK. We started on the actual implementation of the invisible proxy. A big question has been whether a HTTP OK is followed by a request for the XML scheme from the control point. This is the case with the Intel device sniffer. If so we will loose some functionality since we cannot spoof a TCP connection (that is needed for retrieving the XML scheme). Instead we will have to wake up the sleeping service for every discovery. Still trying to find the answer to this problem. We did some more writing and are almost finished with chapter 1.
During these three weeks we have built the invisible proxy. The proxy now has full functionality, even though there are some bugs. The proxy can:
The proxy works according to the FSM with one exception: it does not forward packets when a device is woken using WOL. The reason for this is the discussion of when a device really is awake and able to receive and answer packets. Right now we’re assuming that the application will resend packets by itself. We did get an answer for the question of last week: an application does not have to request the XML scheme, but most applications do that. This is unnecessary since all the information a control point needs for presentation is in the HTTP OK. There will be a bigger discussion of this issue when we do an evaluation of our solutions. The complete code for the first version of the proxy will be published shortly. During these weeks we have also finished chapter 1 and chapter 2 of the thesis.
This week we did a fair amount of writing. We added some parts to chapter 1 (FSMs for UPnP service and control point). We also did some smaller changes to chapter 2. We completed the parts of chapter 3 that were possible to write (we can not write anything about the cooperating proxy or service proof of concept yet). We also updated the invisible proxy to make it easier to download and run. It is now a console application and the download files includes source code, executables, project files and complete Netwib library. During this week we started working on the cooperating proxy. The design in form of FSMs was made. We have started with the power management proof of concept. We decided to go with Microsoft's UPnP SDK since it was the only free one we could find for C and Windows. It is very complicated since it uses the ATL COM interface that none of us know, but there are some easy tutorials and step by step instructions that should be sufficient for implementing a power management service.
These two weeks have been spent coding. We have written a power management service using Atinav's Java SDK for UPnP devices. We decided to go with this SDK because Microsoft's SDK was too hard to learn and we simply could not get it to work. The service has one state variable, power. This variable has two values: true or false. True means that the service is fully powered up and false means that the service is in power sleep mode. The service has one action GetPowerStatus that will return the value of the power variable. During these two weeks we have also written the cooperating proxy. It is basically an extension of the invisible proxy. The proxy can:
The proxy works according to the FSM with two exceptions. It does not accept UNSUBSCRIBE messages from the service (transition P11). Just like the invisible proxy this program does not forward packets to a service that has been woken using wake on lan (transition P51a).
Unfortunately we have not updated the diary for some time. The last weeks have been pretty busy. After finishing the implementation of the cooperating proxy we validated both the invisible and cooperating proxy. We designed test cases to cover all requirements, set up a test bed and executed most of the test cases. Some of the test cases could not be executed due to lack of equipment and some testcases were expected to fail because of shortcomings in the design and implementation.
We have made a power savings estimate to estimate how much power can be saved by using our solutions. This estimation was done with the help of Bruce Nordman at Berkely National Laboratory. We estimated stocks, usage patterns and energy consumption for IT equipment in US households in 2008. Our conclusions were that between 75-285 million dollars can be saved, depending on how many households will actually use UPnP.
We have also spent a lot of time writing and finishing the thesis. It is now complete and the final version can be viewed on this homepage. Right now we are preparing the presentation that is going to be on June 7th. We are making slides and preparing our talk. The presentation will be filmed and streamed over the Internet so that anyone that is interested can connect and view it. We will also post the complete presentation on this homepage when it is done.
During these last weeks of the project we worked with our presentation. Making slides and preparing our talk. The slides can be viewed on this homepage. The presentation was held June 7th. We got some questions and comments over the phone from our supervisor at LTH in Sweden and Bruce Nordman at LBNL. We also got valuable questions and comments from the board members at USF and from the audience. The whole filmed presentation can be downloaded from this homepage. Finally the presentation and the thesis was approved by both Dr. Christensen, our supervisor at USF, and Dr. Nyberg our supervisor at LTH. All that is left now is to write a three page popular science article, but this is something we will do when we get back to Sweden. We are also considering to publish part of the work done in this thesis, but that is also something that will be done later.
We have reached the end of our stay in Tampa and we are finishing up, correcting small errors and comments of the thesis. A new version will be posted shortly. We have had a really good time and we thing the project was successful. We will keep working with the UPnP Forum with the standard for power management. This is the last diary entry, and from the time that we leave US this homepage will not be updated anymore, however it will be archived as a part of Dr. Christensen's homepage.