perfsonar-dev - Re: [pS-dev] Efficient large Data transfer
Subject: perfsonar development work
List archive
- From: Jochen Reinwand <>
- To: Joe Metzger <>
- Cc: "Jeff W. Boote" <>, maxim <>, "'Nicolas Simar'" <>, "'Nina Jeliazkova'" <>, "'schmitz'" <>, "'WiN-Labor'" <>,
- Subject: Re: [pS-dev] Efficient large Data transfer
- Date: Tue, 6 May 2008 11:37:30 +0200
- Organization: DFN Verein
On Monday 05 May 2008 17:46, Joe Metzger wrote:
> 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.
The only thing that is important for the perfSONAR protocol is the way the
rsync URLs are put into the perfSONAR messages. What this URLs mean is out of
scope for perfSONAR. This is the basic idea: Make your data available via
some (most likely otherwise standardised) mechanism and use the power of
perfSONAR, especially regarding meta data, to point the other communication
partners to that source.
> 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?
It's an enhancement to the protocol and another way of accessing Hades (and
perhaps even other) data. The first one is a simple enhancement possibly
useful in some other cases. The later is a new functionality that has nothing
to do with perfSONAR, but that we should not hide from users either.
> 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.
Perhaps you like this description better: It is a perfSONAR compliant service
enhancement that allows fast data access via Perl storables and rsync. It is
especially useful for a specific purpose (fast interaction between to
specific perfSONAR tools), but can be useful in other cases, too.
Can you please give a good reason why it shouldn't be possible to include a
URL as data in perfSONAR messages? I simply don't see the point...
Jochen
--
Jochen Reinwand, DFN-Labor
Friedrich-Alexander-Universität Erlangen-Nürnberg
Regionales RechenZentrum Erlangen (RRZE)
Martensstraße 1, 91058 Erlangen, Germany
Tel. +49 9131 85-28689, -28800, Fax +49 9131 302941
www.win-labor.dfn.de
- ***SUSPECTED SPAM*** Re: [pS-dev] Efficient large Data transfer, Jeff W. Boote, 05/05/2008
- Re: [pS-dev] Efficient large Data transfer, Joe Metzger, 05/05/2008
- Re: [pS-dev] Efficient large Data transfer, Jochen Reinwand, 05/06/2008
- Re: [pS-dev] Efficient large Data transfer, Jeff W. Boote, 05/06/2008
- Re: [pS-dev] Efficient large Data transfer, Jochen Reinwand, 05/07/2008
- Re: [pS-dev] Efficient large Data transfer, Jason Zurawski, 05/07/2008
- Re: [pS-dev] Efficient large Data transfer, Verena Venus, 05/07/2008
- Re: [pS-dev] Efficient large Data transfer, Jason Zurawski, 05/07/2008
- Re: [pS-dev] Efficient large Data transfer, Jochen Reinwand, 05/07/2008
- Re: [pS-dev] Efficient large Data transfer, Jeff W. Boote, 05/06/2008
- Re: [pS-dev] Efficient large Data transfer, Jochen Reinwand, 05/06/2008
- Re: [pS-dev] Efficient large Data transfer, Joe Metzger, 05/05/2008
Archive powered by MHonArc 2.6.16.