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

["Kornmayer, Harald" <Harald.Kornmayer@xxxxxxxxxx>]

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
>>