perfsonar development work

[Maciej Glowiak <>]

ulisses wrote:
> Hi Maciej,

Hi Ulisses,

> I don't remember if I have asked you this in the past, could you answer them? 
> please note
> that I'm going to be away until 21st of agust. Thanks so much.
>
> Some questions about the protocol:
>
> - about the register message
>
>   the following fields [1] must be filled?
>
>   <nmwg:data id="data0" metadataIdRef="serviceLookupInfo"> [1 // includes 
> it's childs]
>        <nmwg:metadata id="meta1">
>            <perfsonar:subject id="subj1"       
>                    xmlns:perfsonar="http://ggf.org/ns/nmwg/tools/org/perfsonar/1.0/";>
>                <nmwgt:interface 
> xmlns:nmwgt="http://ggf.org/ns/nmwg/topology/2.0/";>
>                    
> <nmwgt:hostName>atlang-hstnng.abilene.ucaid.edu</nmwgt:hostName>
>                    <nmwgt:ifName>unknown</nmwgt:ifName>
>                    <nmwgt:ifDescription>
>                          
> hstn:oc192(p2p)::show:intracloud</nmwgt:ifDescription>
>                    <nmwgt:ifAddress type="ipv4">198.32.8.34</nmwgt:ifAddress>
>                    <nmwgt:direction>in</nmwgt:direction>
>                    <nmwgt:capacity>10000000000</nmwgt:capacity>
>                </nmwgt:interface>
>            </perfsonar:subject>
>            <nmwg:eventType>utilisation</nmwg:eventType>
>        </nmwg:metadata>
>
>
>   If yes, I don't understand the need for such fields

Yes, they're required. Why? Because of the schema and NMWG. Please ask 
Martin or Jason for details.

>   Also, if the register message doesn't contain [1], maybe there is not a lot of 
>   advantage having a separate keepalive message. Currently I periodically re-register.
>   Is this wrong? Probaly I should use a sepparate the keepalive the message, 
> isn't it?

Now the registration component is very simple, just re-register data. 
But if you have a lot of data, you may just send keepalive message and 
LS will know that lookup information shouldn't be removed.

> - about the Keep alive message:
>
>         
> http://wiki.perfsonar.net/jra1-wiki/index.php/Example_LSKeepaliveRequest
>         
>   I understand that the only field that has to be customized to each service 
> is the URL that
>   points to the service:
>
>         <nmwg:parameter name="lsKey">
>                 
> http://reed.man.poznan.pl:8080/axis/services/MA</nmwg:parameter>
>         </nmwg:parameters>
>
>   and the URL should match be the same as in the accessPoint of the register 
> message:
>
>   <psservice:accessPoint>
>                      http://reed.man.poznan.pl:8080/axis/services/MA
>   </psservice:accessPoint>
>
>   otherwise, the keepalive will not take place. The rest of the message should be as is in the example. 

Right, keepalive contains lsKey given back after registration. The key 
is accessPoint, because Lookup Service works in such way, but it might 
be anything else. So - lsKey, not accessPoint.

So the idea is:

1. You register to LS
2. LS gives you back a KEY
3.
   a. if no changes in your local lookup info -> send KEY to LS
   or
   b. if there are some changes -> re-register data
4. go to 3.


> - also maybe you should update the page 
> http://wiki.perfsonar.net/jra1-wiki/index.php/Lookup_Service_Protocols
>   when you say "Hierarchy of result and error codes, and their implementation, are 
> still the subject of discussion."
>
>   and instead put a reference to ls.success.registration and update the 
> eventType in the example XML response?
>
>   http://wiki.perfsonar.net/jra1-wiki/index.php/Example_LSRegister_Response

Yes, thanks, it should be updated. i'll keep it in mind.

Maciej

--

 --------------------------------------------------------------------
| Maciej Glowiak        Network Research and Development            ||
| 

     Poznan Supercomputing and Networking Center ||
| (+48 61) 858 2024     http://monstera.man.poznan.pl/              ||
 ====================================================================