perfsonar development work

[Maciej Glowiak <>]

Guys,

As you probably know, I am not officialy working on perfSONAR any more, 
however I will try to support Slawek in his further development of the LS.

The parameters negotiation will certainly need some more "negotiation" 
on one of next meeting. I know there is a need of global solution for 
such a negotiation process for all services (especially MP), however we 
 can still implement something very simple what can be the "part" of 
the future solution.

For me it seems keeping it simple will be the best way of implementing 
it for now:

1)  Service: register me with TTL 300 sec

  2a) LS: no, ttl is too low
  or
  2b) LS: no, ttl is too high
  or
  2c) LS: registration successful

2a and 2b will need, as Slawek wrote, next registration. Of course if 
much data is sent, it won't be optimal, but implementing stateful 
sessions will not be possible easily now.

Jeff, I fully agree, the response from the LS should be 
machine-parsable. Can you or Jason propose the format? Perhaps you 
already have something for psPS?

Best regards
Maciej


Slawomir Trzaszczka wrote:
> Hi Jeff,
>
> I have no idea about response (with rejected parameter information)
> message format. I think that parameter negotiation should be very easy. 
>
> Client send request to  service (e.g. LookupService). Sent message has
> parameters (e.g. lsTTL parameter). If the parameters are incorrect,
> message will be processed but parameter will be rejected. Response
> message will have to contain information about parameters mistake (e.g.
> out-of-bound) and information about this parameter limitation (correct
> value). If the client will want to send new parameter, he will send
> registration message with new (improved) parameter to service. Correct
> parameter will be accepted and information about it will be send to the
> client (parameter accepted).
>
>
> thanks, 
> Slawek.
>
>
> On Thu, 2009-07-02 at 10:03 -0600, Jeff W.Boote wrote:
> > Hi Slawek,
> >
> > A few of us have been discussing this and would like some more time to  
> > think about the implications.
> >
> > Specifically, one concern is that this might really be another case of  
> > needing session state in the protocal. (i.e. the ability to do some  
> > negotiation between the client/service.) If so, this is not too  
> > different from what will be needed to negotiate a future execute  
> > schedule or other parameters in the MP case. In which case, from a  
> > protocol perspective I would want these kinds of things handled in the  
> > same (or at least similar) way - not as a series of one-off's added  
> > when each individual developer decides they need this kind of feature.
> >
> > Do you have some thoughts as to how the method you have suggested  
> > below would be applicable to other 'negotiation' types of use cases?
> >
> > One suggestion I have regarding your proposal, is that not enough  
> > information is returned that is easily machine-par-sable.  
> > Specifically, you have the upper limit in the human-readable part. But  
> > not as part of a defined data type that a service could reasonably  
> > decode and make a different decision without human intervention.
> >
> > thanks,
> > jeff
> >
> > On Jun 25, 2009, at 1:16 AM, Slawomir Trzaszczka wrote:
> >
> > > Hi all,
> > >
> > > I'm working on lookup service. I would like to ask you few questions
> > > about lsTTL parameter and nmwg message form. I'm implementing lsTTL
> > > parameter handling by lookup service.
> > >
> > > New feature is used when a service wants to register to lookup service
> > > and send lsTTL parameter.
> > >
> > > LsTTL (TTL - time to live) parameter is used when the lookup service
> > > cleans up old services. Latest Lookup Service implementation uses  
> > > global
> > > lsTTL for all services registered in database. In new version, service
> > > which want to register to lookup service, can send own lsTTL  
> > > parameter.
> > > This parameter will be prevented and it will ignore global lsTTL.
> > >
> > > Message from service, with lsTTL parameter:
> > >
> > > <message type="LSRegisterRequest">
> > >   <parameters id="parameters.1">
> > >     <parameter name="lsTTL">300</parameter>
> > >   </parameters>
> > >
> > >   <!-- ... -->
> > > </message>
> > >
> > >
> > > The problem is how can lookup service inform client that sent lsTTL
> > > parameter is accepted/rejected(incorrect,out of bound) - in which part
> > > of nmwg message?
> > >
> > > This is my proposal :
> > >
> > >
> > > <nmwg:metadata id="M_E_T_A_1">
> > >   ...
> > > </nmwg:metadata>
> > >
> > > <nmwg:data id="result-code-description" metadataIdRef="M_E_T_A_1">
> > >
> > >   <nmwgr:datum xmlns:nmwgr="http://ggf.org/ns/nmwg/result/2.0/";>
> > >        Data has been registered with key ...
> > >   </nmwgr:datum>
> > >
> > > </nmwg:data>
> > >
> > > <nmwg:metadata id="result-code1">
> > >      <nmwg:subject id="reference-to-metadata"
> > > metadataIdRef="M_E_T_A_1"/>
> > >
> > >        <nmwg:eventType>
> > >        http://ggf.org/ns/nmwg/result/2.0/warinig/ls/ttl_out_of_bound
> > >        </nmwg:eventType>
> > >
> > > </nmwg:metadata>
> > >
> > > <nmwg:data id="result-code-description1"  metadataIdRef="result- 
> > > code1">
> > >      <nmwgr:datum>
> > >                Miminimal TTL is 90 sec. Your was 80 sec.
> > >      </nmwgr:datum>
> > > </nmwg:data>
> > >
> > > What do you think about this response ? Is it correct ?
> > >
> > > Regards Slawek


--

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

     Poznan Supercomputing and Networking Center ||
| (+48 61) 858 2024        -- skype_id: maciej_psnc  -- GG: 4526858 ||
|                          -- jabber:   

    ||
 ====================================================================