Hi,
I'm confused, as I thought that the passive option was simply passed
through to the underlying transport - in this case, g-u-c. I don't
think SRM has any concept of passive / active, it's just a web service.
Can I suggest forgetting about the SRM layer for now, and seeing if a
straight globus-url-copy works in one direction or the other?
Cheers,
Dave
On 25 Sep 2007, at 15:03, Jon Wakelin wrote:
> Hi Dave,
>
>> I vaguely recall that the meaning of -server_mode=passive depends
>> on the data direction... could be wrong though...
>
> It's true in that you can copy data /from/ the WN to the SE - even
> using parallel streams. But it doesn't help us if we want to do
> the reverse.
>
> The problem is that while the DPM server (or whatever is listening
> on 8443!) starts off communicating passively, at some point it
> hands off the actual data transfer to the gridftp-server. At this
> point the connection stops being "server-passive", the gridftp-
> server starts actively trying to make connections to the globus-url-
> copy client on the worker node. But the worker is on a private
> network so there is no route to it.
> SNAT can guarantee the two-way communication with the outside
> world /provided /that the client initiates the communication (it
> does this through session tracking - and keeps a record of
> established streams). But if the SE starts a new communication
> (for which there is no existing session) then iptables has no idea
> where to route these packets to (in fact - it just assume that they
> are intended for the local machine (i.e. the NAT box itself)).
> This is why I thought DNAT might help - but I'm beginning to doubt it.
>
> At the moment you can copy files /to/ the SE with any number of
> streams. And you can copy files /from/ the SE using a single
> stream. Possibly we can set streams_num=1 as the default somewhere
> - or maybe we can rely on users to set it! Maybe that is good
> enough, maybe it's what other sites have to do. Either way we can
> communicate between SE and WN (with one caveat).
> regards
> Jon
>
>
>>
>> Dave
>>
>>
>> On 25 Sep 2007, at 13:34, Jon Wakelin wrote:
>>
>>> OK, I'm starting to get a better understanding. Using the flag
>>>
>>> -server_mode=passive
>>>
>>> should mean that /all/ connections are initiated by the client -
>>> and if that is the case then there shouldn't be any problem using
>>> SNAT (as with regular FTP & SNAT). But even with
>>> server_mode=passive srmcp still hangs at:
>>>
>>> GridftpClient: gridFtpRead: starting the transfer in emode
>>> from lcgse01.phy.bris.ac.uk:/raid/sdb1/dteam/2007-09-24/
>>> filename1.txt.345461.0
>>>
>>> Looking at tcpdump on my worker node I see various packets
>>> between SE and WN - all of which are initiated by the WN (client)
>>>
>>> WN:34851 <-> SE:8443
>>> WN:34852 <-> SE:8443
>>> WN:34852 <-> SE:2811
>>>
>>> but the communication stops at this point. If I compare with the
>>> same command on a non-NAT box I see that (parallel)
>>> communications continue from this point over the
>>> GLOBUS_TCP_PORT_RANGE ports. e.g.
>>>
>>> SE:20000 -> WN:34854
>>> SE:20001 -> WN:34854
>>> SE:20002 -> WN:34854
>>> etc ...
>>>
>>> AFAICT - these connections are initiated by the gridftp server /
>>> from/ the SE - /this is not passive/ - so there is no way for
>>> SNAT box to deal with it. The only way I can see to force
>>> gridftp server to use passive mode is to use a single stream (as
>>> Brian mentioned). So I'm sort of stuck.
>>> The server_mode flag of srmcp does not appear to affect the
>>> gridftp server - it certainly doesn't seem to put it into passive
>>> mode (in fact I don't think GridFTP/globus-url-copy can do
>>> parallel and passive). So I think I have a better understanding
>>> of the problem, and still no idea about a solution. Does that
>>> make sense? Does anyone have any comments/ideas?
>>>
>>> regards
>>> Jon
>>>
>>>
>>> Jon Wakelin wrote:
>>>> Hi Brian,
>>>>
>>>> you're exactly right - I found this out about 2.00 AM today
>>>> (wish I'd gone to bed now). smrcp does work with -
>>>> streams_num=1 but not with any kind of parallelism. I will look
>>>> into some of the pushmode switches that you mention. Does anyone
>>>> have parallel transfers working with NAT? If so could I peek at
>>>> your iptables? I'm assuming that the additional streams (in a
>>>> parallel transfer) appear as completely new packets at the NAT
>>>> box (i.e. the are not seen to be related to the initial
>>>> communication) and therefore the box does not know to route them
>>>> onto the private network. I've tried using DNAT (in addition to
>>>> SNAT) to get around this - but it doesn't work yet.
>>>>
>>>> thanks again
>>>> jon
>>>>
|