perfsonar development work

[Jason Zurawski <>]

Roman Lapacz wrote:
> One more thing:) this is one of the examples from pSB doc:
>
> <nmwg:message type="MetadataKeyRequest" id="metadataKeyRequest1"
>              xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/";
>              xmlns:iperf="http://ggf.org/ns/nmwg/tools/iperf/2.0/";
>              xmlns:nmwgt="http://ggf.org/ns/nmwg/topology/2.0/";
>              xmlns:nmtm="http://ggf.org/ns/nmwg/time/2.0/";>
>
>  <nmwg:metadata id="m1" xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/";>
>    <iperf:subject xmlns:iperf="http://ggf.org/ns/nmwg/tools/iperf/2.0/"; 
> id="subject-1">
>      <nmwgt:endPointPair 
> xmlns:nmwgt="http://ggf.org/ns/nmwg/topology/2.0/";>
>        <nmwgt:src type="ipv4" value="198.32.8.170" port="5433"/>
>        <nmwgt:dst type="ipv4" value="198.32.8.174" port="5433"/>
>      </nmwgt:endPointPair>
>    </iperf:subject>
>    <nmwg:eventType>http://ggf.org/ns/nmwg/tools/iperf/2.0</nmwg:eventType>
>    <nmwg:parameters id="parameters-1">
>      <nmwg:parameter name="protocol">TCP</nmwg:parameter>
>    </nmwg:parameters>
>  </nmwg:metadata>
>
>  <nmwg:metadata id="m1c" xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/";>
>    <select:subject id="s1c" metadataIdRef="m1"
>                    xmlns:select="http://ggf.org/ns/nmwg/ops/select/2.0/"/>
>    <select:parameters id="p1c" 
> xmlns:select="http://ggf.org/ns/nmwg/ops/select/2.0/";>
>      <nmwg:parameter name="startTime" 
> type="unix">1105452600</nmwg:parameter>
>      <nmwg:parameter name="endTime">1105453100</nmwg:parameter>
>    </select:parameters>
>    <nmwg:eventType>http://ggf.org/ns/nmwg/ops/select/2.0</nmwg:eventType>
>  </nmwg:metadata>
>
>  <nmwg:data id="d1" metadataIdRef="m1c" 
> xmlns:nmwg="http://ggf.org/ns/nmwg/base/2.0/"/>
>
> </nmwg:message>
>
>
>
> Am I right that the presence of protocol parameter in request's metadata 
> (m1) means that it is (might be) also present in metadata configuration 
> file's metadata(s)? Is this parameter used in the MetadataKeyRequest 
> message as a filter?


The parameter should always be there for each tests (UDP or TCP; I 
believe the rational here was that there may be separate parameters for 
a test even to the same host pair).

You can use it like a filter, but assume that the value is in the store 
and could be either TCP or UDP.

-jason