Contacts:

Sara Masood a student of Saqib at the UOA in Pakistan provided a mock-up of what she was thinking about. After reviewing it Les came up with 3 scenarios 2/16/2016:

1. Is to just use the cell phone like we used the Raspberry pi to provide a PingER Measurement Agent (MA). Initially the android would be stationary and have a  network connection. This would probably be WiFi. I doubt for this application we would want to pay a carrier for a phone subscription, especially since PingER runs 24 hours/day 365 days per year. We would need to be able to access the Android remotely at least daily to gather the data to the central repository at SLAC.  Normally this is done by a wget to the web server on say the MA. A new method may need developing. This was originally what we were thinking of with the example of placing an MA at Say Bario on the Borneo Highlands.
2. Is to act as a user app, i.e. make on demand ping measurements to some targets. They could be well known PingER targets in which case a way to select the ones of interest may be needed (e.g. by country, by region).  An alternative would be to have a default list of PingER targets representing regions of the world (e.g. the Beacons list or a subset which would need to be provided centrally).  A map would be displayed showing the beacons (colored or sized by the metric RTT, loss throughput, jitter, etc.). Clicking on the beacon would show information about the target plus a time series graph of the metric.
3. Let the user provide the target. The downside is we do not know where the target is, thus cannot plot it on a ma, and there are lots of apps like this.

Topher responded 2/16/2016

• In my opinion, #1 is the most promising. It's also the most similar to the type of functionality you could build upon simply by forking the RFCx code, as suggested. It would be most reasonable to ignore the cell network altogether and simply use Wifi, since the latency of cell networks are incredibly high and also unrepresentative of what pinger has been measuring to date. Local Wifi latencies are not inconsequential, but they can be regularly measured (by pinging and base station) and calculated (subtracted) from the measurements.

• Periodically sending the data payloads to the server (not with wget but with a pretty standard http request in java) is not difficult to implement. It's also a part of the RFCx repos, and could be used as a place to begin. With RFCx, we regularly send commands back to the remote phones as part of the http response. That seemed to be something that you wanted to use as well.

• Happy to discuss by phone or Skype sometime if it could add clarity

Sara responded 2/17/2016

• In 1st point, mobile phone measuring agent will send pings to the targets, and Save RTT locally in a database which will be pulled by SLAC on daily base via Http Request from the mobile phone measuring agent. Android ICMP Ping API can be used that will return RTT using WIFI and send commands/ping back to remote mobile agents by Http Request. To implement this functionality following web services are required:

  • Request to pull all remote nodes file to ping. This file is available at http://www-iepm.slac.stanford.edu/pinger/pinger.xml

  • Request to send/save data on SLAC on daily basis. Currently this is obtained by a GET from SLAC. We may need to develop an alternative way to get the ping results to SLAC.

  • Request to get commands/ping from other remote host. This is not needed.

• In 2nd point, separate user application, that give option to user may be using drop down list to choose to and from region epoch time, metric (RTT, jitters, etc.) and on selecting desired region plot show beacons colored by their RTT, Jitters. and on clicking show popup with their info (IP, Name, etc.) and time series graph.