Adam Hodges CPSC481/CyberTiger Project Proposal 1/31/12. Motivations

Transcription

1 Adam Hodges CPSC481/CyberTiger Project Proposal 1/31/12 Motivations It is my goal to continue my work from the summer and fall semesters in order to learn more about wireless networks and their characteristics by continuing to develop the CyberTiger network testing framework and gathering data to populate our visualization. Background My previous work on this framework has mostly consisted of design and implementation. Our testing tool is mature enough to the point where it can provide a versatile platform for any kind of network based test to be implemented. There has been a recent trend of crowd sourcing of data in mobile applications. This has been influenced greatly by the smartphone market, where a large amount of users can have an application deployed to them. Users can then generate data and report back to a server. This is the idea behind the CyberTiger testing app. It is our goal would like to motivate users to generate enough data for us to analyze. Objectives Project #1 Stress test the framework in an attempt to make the framework as robust as possible Add more controls to the visualizer for the purpose of filtering data Explore new visualization methods Collect a reasonably large amount of data using the framework Open the usage of our testing tool to the general public Assist in the creation of an iphone client for our framework Project #2 Methodology Create an availability tool to periodically report signal strength and RTT of a device Find an incentive to attract users to run our tool in the background Investigate issues battery life and privacy I plan on overhauling the server code to improve robustness. Improvements will include: logging, error handling, timeouts, and running the server program as a persistent service. Upon completion of this task, there should be no error case that the server wouldn t be able to recover from.

2 A good deal of time will need to be spent on this, including testing with different devices and platforms. The goal is to produce code that is production quality. More controls will be added to the visualizer simply by adding them to the layout of the map in the Javascript code. The work to be done regarding adding filters to the visualizer is relatively trivial as far as programming goes. The data is already available, and some controls have already been implemented. The true obstacle is producing an aesthetically appealing interface to our visualization map that allows users to effortlessly sort and visualize the desired data. I will be helping Joshua in his development of an iphone client to our framework. I have explained to him what a reasonable phase 1 of the project would be, which is the collection of signal and location information. This is platform specific, and requires some level of expertise in iphone application development. Once that ground work has been completed, the rest of the application is socket programming. We will have to continue brainstorming a motivation for people to use an availability tool. There is the inherent motivation of them being able to visualize their personal network strength, but there will have to be some other feature that attracts users from a wider demographic. I will try to find some papers on how much GPS tracking affects battery life in modern smartphones, and see if there is a preferred polling interval that maximizes battery life, privacy, and quantity of data collected. The implementation of the tool will be fairly simple. It will just be a test in our framework that consists of only a ping to gather RTT, and it will run in as a persistent background service on the client s phone. Throughout the semester I will be conducting a literature survey. I will be actively searching for research papers that are relevant to my studies, including bandwidth testing, coverage mapping, and recording human mobility patterns. I will keep a collection of these papers and write a brief summary on each, along with an explanation of how it is relevant to our work. Expected Outcomes/Results At the end of this semester I think it s safe to assume that we will have a polished product version of our testing tool. The majority of error cases should be handled appropriately in both the Android client and the C++ client. The server code will have to be a little more mature to handle some of these cases. Our visualizer should be improved, with filters for types of network, as well as provider. The UI should be improved in general. A visualization closer to a heat map is possible, but will require some collaboration with students from the visualization lab. Also, a basic availability tool should be completed. This tool should be able to be run in the background of a user s phone without a significant impact on battery life or phone performance. This app will have a very small footprint.

3 Deliverables 2/10: All obvious error cases in Android client and C++ server handled. 2/17: A week s worth of data collection and stress testing (using TCP bandwidth tests) 2/24: Improved basic visualizer (add filters), continue testing 3/2: Project #1 complete 3/9: Availability tool halfway complete 3/16: Basic availability tool finished 3/23 (not in lab, spring break): Use availability tool, note any bugs, make note of battery usage. 3/30: Attempt to fix any bugs uncovered in previous week of usage 4/6: Create user portal to access personal logged data, their custom map 4/13: Finish basic user portal 4/20: Mulligan week 4/27: Final progress report, fully documented code

4 Adam Hodges CPSC481/CyberTiger Final Project Report 4/24/12 Deliverables My efforts on this project were spread across multiple fronts this semester, but I was still able to get a considerable amount done and move us closer to having a product stable enough for a public release. In addition to my initial goals, I have also been helping Josh and Neeraj become familiarized with the framework and helping them move along in their progress. My first deliverable was to advance the server and Android code to the point of production quality. This proved to be a semester long effort, as new bugs are always being uncovered. However, the code has matured to the point where it can be released to a small group of beta testers. The server has been daemonized, with all output redirected to a log file that resides on /tmp/cybertiger.log. The server makefile has been extended to include a make install option which will install the program as a service on the machine and add a CRON script that will ensure that the server is running at all times. select() timeouts have been added to all socket calls in the server code. The Android client has also had timeouts added to its socket interactions. A few small bugs in the code were fixed, along with the restructuring of the Preferences menu. Users have been presented with additional options to change how the location is determined, and settings for specific tests. A new app icon has been made for the app, and we are now using version numbers to describe builds for error reporting purposes. The UDP bandwidth test previously had some inexplicable issues, which I was able to narrow down to an issue of NAT traversal. The client was able to send UDP packets to the server from any network, but some networks did not allow the client to receive UDP packets. This was solved by the use of UDP hole punching, a technique in which you punch a hole in the NAT by having the client send a UDP packet to the server before any other interaction occurs. This technique has been extended to our other UDP tests, like the streaming test, and has fixed the inexplicable issues that we were encountering there as well. There were a few other bug fixes I did to the UDP bandwidth test, and when I was comfortable with the stability of the test I turned on database logging of the results. The visualizer underwent an overhaul this semester. I made extensive use of the jquery Javascript library in my improved visualizer. Upon the addition of a data point to our map, the point is assigned a CSS class, which is a label by which you can select a group of elements. The map filters were built by selecting on these classes and including/excluding data accordingly. I experimented with another feature in jquery, which is the asynchronous calling of web services. This allows you to get data dynamically and without refreshing the page. I used this to make an autocomplete SSID filter field, which helps users pick a WiFi SSID by which to filter the map. This might need to be restricted in the future for privacy issues.

5 I wrote a new test named Ping. This test is simply a copy of the first portion of the TCP bandwidth test, in which 3 TCP based pings occurs. The results of this ping are stored in the database. The TCP bandwidth insert procedure in the database needs to be revised so that the ping results are stored separately in the ping table instead of in the TCP bandwidth table, and the ping column in that table needs to be removed. This ping test has replaced the geolocation log (which is still a valid test ) in the Android client as the first button. We should consider moving towards an ICMP based ping in the future. I do not think the TCP one is very accurate. My second project of the semester was to make an availability tool. This is something that we had previously discussed but never fully investigated. I was able to re use code from our existing tool as groundwork for this tool. This tool is implemented as an Android service, which differs slightly from a traditional app in that it runs in the background of the phone. There is a front end app that is used to start/stop/configure the service, but most of the code is run in the background. This service collects location/signal information, pings the server with this information, and then re schedules itself to run again at a set interval in the future. This interval is currently a default of 30 seconds, but that is far too frequent for any practical usage of this app. My preliminary testing shows a significant impact on the phones battery life for a 15 second interval, but a much larger interval should not have much of an impact. I wrote an instruction manual to go along with our testing app. The goal of this was to provide testers with a guide on how to install the app, configure the preferences, and explain the expected behavior of the tests. Issues/Future Work I encountered a few issues during my work this semester, the largest of which was when I realized that tests on Verizon s 4G LTE network had bad data. The reason behind this, as I discovered, is because our app uses a dated version of the Android API in which support for LTE networks had not yet been implemented. However, if we use a more current version of the API we will lose compatibility with a significant number of devices. There is no way to change the API version programmatically. This is an issue that is encountered in other apps, and the traditional way of getting around it is by posting multiple versions of the binary to the Android market. The Android market then intelligently determines which version to give to the user based on their phone version. Unfortunately, we are not using the Android market yet so this solution is infeasible. The only solution that I have found is for us to post two separate binaries on our website and trust our users to pick the appropriate one. Either way, we will need to start maintaining two separate versions of our app. I never got around to adding the custom user portal that allows users to see their personalized coverage map. The coverage map could always stand to be improved, and that will be one of the major functionality improvements. I also believe we need to move towards a heat map design.