[gin-data] SRM interop plan

[William E. Allcock]

Please be more precise in what problem you are seeing.  GT3.2 client and
server could mean any client or server.  Which clients and servers are
giving you trouble?  I know of no known compatibility issue with the GridFTP
clients and servers from those versions.

Bill

> -----Original Message-----
> From: owner-gin-data at ggf.org [mailto:owner-gin-data at ggf.org] 
> On Behalf Of Alex Sim
> Sent: Wednesday, April 19, 2006 11:31 AM
> To: 'Jensen, J (Jens)'; 'Aleksandr Konstantinov'
> Cc: Erwin.Laure at cern.ch; gin-data at ggf.org; 'Srm-Devel (E-mail)'
> Subject: RE: [gin-data] SRM interop plan
> 
> Recently we encountered a problem in communication between 
> GT3.2 and GT4
> client and server. GT4 client doesn't reach the GT3.2 server 
> any more, nor
> vice versa, through the same interface, whereas they do 
> communicate within
> the same GT versions. I'm not sure if it's related to this 
> GSS module issue,
> and there seem few issues around framework and versions. 
> These are important issues that we as a collaboration have to 
> resolve for
> our interoperation and compatibility. Let's try to compile 
> the list and
> discuss in one of the conf calls and/or meetings.
> --Alex
> 
> | -----Original Message-----
> | From: Jensen, J (Jens) [mailto:J.Jensen at rl.ac.uk] 
> | Sent: Wednesday, April 19, 2006 12:51 AM
> | To: asim at lbl.gov; Aleksandr Konstantinov
> | Cc: Erwin.Laure at cern.ch; gin-data at ggf.org
> | Subject: RE: [gin-data] SRM interop plan
> | 
> | Hi Alex,
> | 
> | This is because in Globus 2 at least, it turns out that if 
> | you build your server/client with GLOBUS_IO_MODULE then it is 
> | apparently incompatible with servers/clients built on top of 
> | the lower level module GLOBUS_GSSAPI_MODULE [module names 
> | from memory so may be slightly wrong].
> | 
> | Now Aleksandr discovered this independently and dug a bit 
> | deeper than we had done, but it still appears that these are 
> | incompatible.
> | 
> | This is mainly important for the SOAP stuff because as you 
> | say it goes via HTTPG.  The de-facto standard in LCG is the 
> | GSSAPI module approach.
> | 
> | Even if you don't care about HTTP as a data transport 
> | protocol, Aleksandr's point is still valid.  It's a question 
> | of testing different implementations of GSI sockets.
> | 
> | Cheers,
> | 			--jens
> | 
> 
> 
>