Page History

...

1. The Android Team at Amity already has the android app in place. The app is capable of parsing the beacon list available at SLAC, and using it to ping all the beacons. The ping command's outputs are then stored in a txt file in a specific directory.What remains is to establish a way by which these generated txt files are sent to the server at Amity in a secure fashion. Les> Agreed
2. Additional requirements on top of standard PingER (e.g. proxy, new implementation of MA and why do not use perl and simply port existing MA pinger2.pl <http://pinger2.pl> );
   1. Our new suggested approach now involves replacing the perl scripts (executing on fixed line machines), with android apps on new portable MAs (ie, android phones). This would result in more diverse data to SLAC for analysis.
   2. The older approach as outlined in Rohan Sampson and Shiv Rajappa's paper involved the use of the pinger2.pl <http://pinger2.pl>  perl script and porting it to android. However, the downside of that approach is that the script could only be run using an emulator on a rooted android phone (equivalent of jailbreak on iOS). Rooting a non-rooted phone is not only illegal in Google's eyes, but also requires a lot of technical setup, which is something not-so-foolproof to be used in developing countries. The rate of failure to even get the app running in such a scenario is very high, as compared to our new developed solution. Les> Agreed.
   3. Our solution doesn't require any form of rooting, or using any emulator to run a script. The code to ping a beacon, parse the output, and also to update the list has been made from scratch. Our new existing setup involves a user to only install the android application like any other application (like whatsapp) on any android device irrespective of whether it is rooted or not.
   4. Les> Excellent
   5. This approach thus deviates from using a singular perl script, but rather adopting a modular approach that can be scaled accordingly. To achieve this vision, we suggest sunsetting the existing pinger2.pl <http://pinger2.pl>  services from the servers at Amity. Rather, the server should only act as a proxy/medium/middleman between the Android MAs and SLAC.
   6. Les> Personally I would retain the existing wired pinger2.pl MA so you can compare etc with the new Android/wireless version.
3.  how results may be affected by wireless access versus wired PingER MA's;
   The ping-command outputs from a wired MA will always be more predictable over a period of time. Fixed lines usually aren't affected by factors such as weather, geographical location, etc. A portable wireless MA allows a user to gather data from different locations, and over multiple transmission mediums (cellular, wifi, etc.). Such diverse data results in high quality datasets for analysis by SLAC. The app can also be tweaked in the future to generate a few more data points (like GPS location, and connection type) that currently arent being used by PingER. This can aid in a deeper analysis.
4. Benefits such as low power, space;
   Earlier the servers at Amity were the MAs, and did not produce much amount of data, and neither was it so diverse.
   Now, in our proposed model, the servers at Amity act only as a proxy. The Android Apps are the new MAs.
   This new model now provides multiple advantages advantages, such as:
   1. more quantity data accumulated
   2. more diverse data accumulated
   3. failure of one MA does not affect the functioning of other MAs

      1. Les> that is also true with the wired MAs

   4. Android devices are hugely popular. Deployment shouldn't be a problem.
   5. The application can run in the background without affecting the user's activities

      1. Les> Also true of the wired MAs, they do not have to be dedicated

   6. Mobile devices consume considerably less power than PCs
   7. Mobile devices are portable, and can be taken to more places for data collection.The Android Application takes up only a few MBs to install, as compared to a full server in Linux and its dependencies.

      1. Les> Thie second sentence may need some clarification. pinger2.pl takes only 64KB, it needs a perl interpreter, temporary storage space and  an OS (Linux). I assume the Android provides an API,  temporary storage space, and the Android OS. Thus at the top level they have a lot of similarities.

5. use cases
   If deployed correctly, using the Android Device as an MA gives rise to whole multitude of possibilities. Only a single MA in an isolated/sparsely populated region can provide sufficient data for IEPM. Places with bad weather, or ones struck with natural calamities, or in remote regions such as rainforests or deserts can bring ground level data for analysis. Since the app stores data locally as well, thus in the absence of internet connection, the app will cache it until a stable internet connection is found. A wired MA cannot provide such dynamic flexibility to the PingER/IEPM project.
   Les> well made points

...