Re: AW: [geclipse-dev] Remote-to-remote transfers with SRM

[George Tsouloupas <georget@xxxxxxxxxxxx>]

It is probably already common knowledge but I'll just go ahead and say
it anyway, that large transfers should be done by submitting a "Data
transfer job". I think JSDL should be able to cover this. 
Do we want to transfer data between different protocols as well? 
e.g. transfer my 1000 1GB files from "xFTP" into LFC?


George.

On Mon, 2007-07-30 at 11:13 +0200, Kornmayer, Harald wrote:
> Dear all 
> 
> what we need is not a "black-white" decision. What we need is a roadmap to a "third party" transfer functionality. By taking all obstacles on the road into account. For me as a "non expert", I don't know what is the right decision know. But here are my few cents: 
> 
> 
> 1. Our framework must offer functionality for "data replication" and "data. This high level service must be offered to the end user. The best would be to support a replica catalog service. 
> 
> 2. The implementation of g-Eclipse must be reliable. That has always high priority. 
> 
> 3. 3rd party transfer is a "must-to-have". You can not pipe TB of data through your laptop.   Giving it a low priority it not the right answer now. 
> 
> 
> So my answer would be in terms of priority rating: 
> 
> -- reliable, SRM-based transfer for local-remote --> +5
> 
> -- implementing replica management features --> + 4
> 
> -- implementing 3rd party transfers --> +3 
> 
> 
> I don't know all the details of the file system. But dependencies of the system have to been taken into account. (Does LFC use SRM-3rd party for "replica transfer"? Or is it pure gridftp? Why is SRM 3rd party not supported by SRM-DPM? Why is it for SRM-dCache? 
> 
> Would be nice if Mateusz can clarify a few of my questions? Or even better, to come up with a roadmap for "Reclipa management" support in g-eclipse!!
> 
> Harald 
>  
> 
> 
> >>-----Ursprüngliche Nachricht-----
> >>Von: geclipse-dev-bounces@xxxxxxxxxxx 
> >>[mailto:geclipse-dev-bounces@xxxxxxxxxxx] Im Auftrag von 
> >>Stuempert, Mathias IWR
> >>Gesendet: Montag, 30. Juli 2007 10:37
> >>An: Developer mailing list
> >>Betreff: AW: [geclipse-dev] Remote-to-remote transfers with SRM
> >>
> >>
> >>Hi Mateusz and others,
> >>
> >>I agree with you, remote-to-remote is a nice2have but nothing 
> >>more at the moment. It is much more important for the daily 
> >>Grid user to have a reliable way of transferring data from 
> >>local to remote and vice versa. And since the redirection via 
> >>local already works this is at least a workaround for the problem.
> >>
> >>So +1 from me...
> >>
> >>Cheers, Mathias
> >>
> >>-----Ursprüngliche Nachricht-----
> >>Von: geclipse-dev-bounces@xxxxxxxxxxx 
> >>[mailto:geclipse-dev-bounces@xxxxxxxxxxx] Im Auftrag von Mateusz Pabis
> >>Gesendet: Montag, 30. Juli 2007 10:31
> >>An: Developer mailing list
> >>Betreff: [geclipse-dev] Remote-to-remote transfers with SRM
> >>
> >>Hi *,
> >>
> >>recently we (that means college from OMII Europe project and me) were
> >>trying to implement 3rd party transfers with SRM (AKA remote-to-remote
> >>transfers).
> >>
> >>This kind of transfer is used to copy/move files between two remote
> >>machines without using client as a proxy. One of them is not needed to
> >>be SRM. The other may be a gsiftp server.
> >>
> >>But, since our SRMs are mostly DPM implementations I have bad news:
> >>DPM server (even on latest 1.6.5 version) does not support 3rd party
> >>transfers. Server returns SRM_NOT_SUPPORTED in most cases.
> >>
> >>I've found this daily SRM tests which can be used to determine which
> >>configuration is supported by which implementation:
> >>
> >>http://datagrid.lbl.gov/v22/index.html
> >>
> >>As you can see, dCache is more reliable in this subject (and 
> >>others too).
> >>
> >>Because of the above I propose to mark remote-to-remote srm transfers
> >>with very low priority.
> >>
> >>and +1 as implicit by this proposal.
> >>
> >>--
> >>Mateusz Pabis
> >>
> >>
> >>_______________________________________________
> >>geclipse-dev mailing list
> >>geclipse-dev@xxxxxxxxxxx
> >>https://dev.eclipse.org/mailman/listinfo/geclipse-dev
> >>_______________________________________________
> >>geclipse-dev mailing list
> >>geclipse-dev@xxxxxxxxxxx
> >>https://dev.eclipse.org/mailman/listinfo/geclipse-dev
> >>
> _______________________________________________
> geclipse-dev mailing list
> geclipse-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/geclipse-dev
>