Hi Greig.
I understood "xroot" and "xrootd" were considered synonymous, rather
than as you'd expect xrootd being the daemon specifically. Been a while
since I've looked at it though - apart from the planning workshop, I
think last time was when I had a long discussion with Andy Hanushevsky
at CERN, that's probably a couple of years ago.
I believe people _are_ thinking about using xroot between sites for SRMs
that both support it, but only in the v-e-r-y long term. Would require
improved security in xrootd though but I understand there have been a
slew of improvements recently (at least for CASTOR). Security is
managed via plugins I believe (but again haven't looked at it for a while).
In the shorter term, we actually do have the DPM clients installed on
the UI at RAL. Causes no end of confusion with RFIO. I have started
using ROOT for testing though, and ROOT can also do xrootd. Looking at
interoperation would be good if it's a problem but it's not exactly a
showstopper at the moment. I think if we're to start running secure
xrootds then getting the security consistent would be a good start.
Cheers
--jens
Greig A. Cowan wrote:
> Hi Jens,
>
> Starting the discussion early...
>
> I'm not sure what you mean by the interoperation of DPM and CASTOR
> xrootd. xroot (no 'd') is a protocol that clients will use to access
> data on a server (be it DPM, dCache, CASTOR or xrootd itself) across the
> LAN. The servers shouldn't be talking xroot to each other to transfer
> data, that's what gridftp is for. I presume you mean the interoperation
> of the DPM client library with a non-DPM-SE server implementation etc?
>
> Of course, I have to mention that ALICE are in fact using xrootd to
> transfer data across the WAN between sites. They are just crazy though.
>
> Greig
>
>
> Jensen, J (Jens) wrote, On 25/11/08 16:38:
>> Mostly about experiments' use of storage systems, hot topic!
>>
>> http://indico.cern.ch/conferenceDisplay.py?confId=46172
>>
>> Remember, strictly 10:00-10:30, usual password.
>>
>> Thanks,
>> --jens
>>
>>
>
|