perfsonar development work

[Joe Metzger <>]

Jeff & Jochen,
I am not too concerned about the technical details about how
to use messages to exchange RSYC URLs.  I am concerned
about the big picture and how this decision affects the
future of the perfSONAR protocols.

Can you please clarify for me if this will be a private,
internal interface for your service, or if you expect this to be a  
change
to the public perfSONAR protocol that will be used by GUI's and
other services to access the data stored in your service?

What I hope you are doing is using a perfSONAR-like protocol internal
to a perfSONAR service to move data around.  If this is what
is going on, then great, I have no problem. Developers must be able
to architect the internals of their services in any way that
meets their requirements, and passing around language specific
serialized objects is expected internal to a service.



--Joe



On May 5, 2008, at 9:53 AM, Jeff W. Boote wrote:

> On May 5, 2008, at 3:43 AM, Jochen Reinwand wrote:
>
> > On Thursday 01 May 2008 01:47, Jeff W. Boote wrote:
> > > There are far more people in the perfSONAR community than were at
> > > Zagreb.
> > >
> > > It would be good to explain what it is you are doing, and why for  
> > > the
> > > full community.
> >
> > I think most of what we are doing is already explained in this  
> > thread. Are you
> > missing anything specific?
> > There was no detailed explanation about how the rsync URLs are  
> > included in the
> > perfSONAR messages. Indeed I'm not sure here about how much is  
> > already fixed.
> > There were ideas to add the URL to the data element instead of the  
> > data or
> > even use the meta data key mechanism. But I'm not working on this  
> > issue.
> > Perhaps Verena or David (or even Martin) can say more about it.
>
> Yes - it is specifically these details that I personally would be  
> interested in hearing. (What the messages would look like.)
>
> Also, I thought a few of Joe's questions were very good. I think a  
> careful examination of them is what is needed to determine what  
> ways the pS protocol needs to be extended in the future to handle  
> bulk data.
>
> I realize you have short term goals - and I'm not suggesting you do  
> anything different from your current plan. But, I do think we need  
> to answer these questions in the medium to long term. And since  
> this is a problem you are currently working on, I am asking for  
> your insight.
>
> > Is it necessary to change both the transport protocol (rsync), and  
> > the
> > data storage format (Compressed perl Storables) to achieve your  
> > performance
> > objectives?
> >
> > Do you think we need to incorporate "external" transport and/or  
> > data formats
> > into the perfSONAR standards?
> >
> > Does this data exchange need to be considered part of the  
> > perfSONAR framework? Or, could
> > it be considered as a 'backed' interface used by a custom  
> > measurement system (hades)
> > to push data into a perfSONAR Measurement Archive. (Similar to the  
> > way several
> > people are using rsync to update the rrd files served by the rrdma.)
>
> jeff