63 | | In the MH, the pS capability is introduced by including a new pS service that we have called the "IMFRealTime" pS service. (''Note:'' this name may be somewhat misleading and may change in subsequent releases; see discussion below.) The IMFRealTime service is different from a normal Perfsonar service (MA or MP) in the sense that it implements a bit of both. It uses the mh Perl module and expands Perfsonar's configuration file to provide the MP service. However, instead of sending the results to an MA, the collected data are saved locally. |
64 | | |
65 | | The main reason behind this solution is that we want to avoid the delay introduced by adding an extra layer of database between the users and the MP. Consequently, the IMFRealTime service also needs to provide a user interface for real-time user queries in the absence of a standard Perfsonar MA. In essence, the IMFRealTime service acts as a pS MP service (that uses previously developed IMF Measurement Handler capability to gather measurement data), but also looks like a pS MA service to external users who issue queries to obtain measurement data from the Measurement Archive. In fact, internally, it uses shared memory as inter-process communication to access the most fresh data in response to user queries. The shared memory acts as the rendezvous instead of the usual MA database. |
66 | | |
67 | | '''About "!RealTime" Nomenclature: ''' This behavior is obviously not actually "real-time" in terms of the time when measurement is made. In contrast, the original XML-RPC approach is "real-time" in that measurements are "triggered", or undertaken (by the MH) in response to incoming user queries. Rather, the behavior is "real-time" in only the sense that the IMFRealTime service looks for the most recent available data in response to user queries. To avoid this potential confusion, we are considering re-naming the IMFRealTime pS service to something else in future releases, and use the term "real-time" exclusively to refer to cases where actual fresh measurements are undertaken once user queries are received. In the future, we hope to investigate the possibility of triggered real-time measurements using the pS pathway as well; at this time, it appears this may not be a suitable match, since the pS architecture relies on static configuration file for measurements, and thus clearly separates the data query from collection. |
| 63 | ... |
107 | | The diagram above (in "Activities/Findings" section) shows where these tarballs fit in. The pubsub_for_perfsonar.tar.gz file (!PubSub for perfSONAR) replaces the imf.tar.gz file of previous releases: the internal file heirarchy is the same, but the top-level name is different: "imf_pfsr" instead of "imf"; this is a kluge that will be fixed in the next release. As a consequence, this version of the code can '''''only''''' use pS query to reach the MH, the previous XML-RPC option is not available in this cut (the MH is still capable of it). |
108 | | |
109 | | The following developer's notes on the IMFRealTime pS service provide more detail which should be helpful in using this code. This file is also included as "doc/README.imf" in the perfsonar_imf_realtime.tar.gz tarball. In addition, the following diagram of the code organization for the "!PubSub for perfSONAR" module (pubsub_for_perfsonar.tar.gz) may be helpful. |
110 | | |
111 | | * [attachment:release_notes.txt Developer Release Notes] |
112 | | |
113 | | [[Image(PubSub_PerfSONAR_Source_Code_Folder_Structure.png, 50%)]] [[BR]][[BR]][[BR]] |
| 101 | See post-GEC10 status report. The only changes to that code are the tarballs above, and the new pS client (command line and GUI) code. |