FTP and SocketTime Out?

[John Patten]

Thanks for tips Alex...

I went ahead and ping'd the servers. By IP the pings are all good times (3ms). However, FTP clients are also very slow in their initial connecion too.

I do have access to another Mac FTP server. I noticed when I connect by domain name, it errors out with a "500 Connection refused (Winsock error #10061)."  However, IP address will work but only after the long connection.

The script I'm using in my stack is lifted from, I believe, one of Andre's examples.

Here it is:

--------------------------------------------------
on mouseUp
  put "ftp://ftpUser:ftppassword@10.58.1.7/Users/ftpuser/Sites/ftpusersite/" into tServer
  
--Here's where I had to put the socket interval. I didn't even set the timeout interval before.  
set the socketTimeoutInterval to 100000
   
  libURLSetFTPListCommand "NLST"
  
  put URL tServer into tData
  replace crlf with cr in tData
  replace lf with cr in tData
  
  

  
  libURLSetFTPListCommand "LIST"
  put URL tServer into tLongData
  
  repeat with x = 1 to the number of lines of tData
    get line x of tData
    get lineoffset(it, tLongData)
    if char 1 of line it of tLongData is "d" or char 1 of line x of tLongData is "1" then
      put line x of tData & cr after theMenuItems
    else
      end if
  end repeat
  
  put theMenuItems into button "country"
  Set the label of cd btn "Country" to "Country"
  show button "Country"
end mouseUp


At least I have the the winsock error to go back to the network folks with!  

Thanks for the help!

John patten
SUSD



------------------------snip-------------------------------

Message: 8 
Date: Tue, 18 Apr 2006 01:26:36 +0100 
From: Alex Tweedly <alex at tweedly.net> 
Subject: Re: FTP and SocketTime Out? 
To: How to use Revolution <use-revolution at lists.runrev.com> 
Message-ID: <4444323C.908 at tweedly.net> 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed 

John Patten wrote: 

>Last week, the intial connection to the FTP server took about 3-4 sec. This week I have to set the SocketTimeOutInterval to 100000. Once the inital connection is made, I'm able to navigate down through the ftp directory structure through my menu buttons without any delays (I assume because I have an open connections once I've made the inital ftp connection.) 
> 
>This is an ftp server on the local network, accessed via IP addres, and the FTP server is an OSX Server not a desktop Mac. 
> 
>Our network people were replacing a Win2003 server on Friday. 
> 
>Any one have an idea what would cause the intitial ftp connection to take so long now? I'm thinking the instalation of the new Win2003 server must have changed something. DNS...? Probably not cause I'm using IP address to access server? Wins? Ideas...? 
>   
> 
As you say, not DNS 
Shouldn't be Wins 
Ideas ?   No good ones - here are a few mediocre ones ... 

try opening the ftp connection from a ftp client and see if it too sees 
big delays. 

has the Win client been rebooted recently (if not, I'd do that next) 

misconfig ?  - make sure the new WinServer isn't clashing with the IP of 
the MacServer 
try "arp -a" a few times, just check that the mac addr associated with 
the IP address you are using is always the same 

has the MacServer been rebooted recently ? 

is there unusual load on the MacServer (e.g. something on the new 
WinServer opening tcp connections to it, or some misconfigured machine 
keeping too many half-open connections, or some DoS attack ??) 

What's the physical set up on the LAN ?  hubs or switches ? Is Win2003 
server on same segment as either of the other machines ? 
Is it possible the new Win server is heavily used, and is having 
noticeable effect on the network load ? 
     (though that would likely affect subsequent operations, not just 
the initial open) 

from the Win client, try pinging the Mac server - check if the times are 
consistent and low (and of course that all packets / replies get through 
- you ought to get 100% success almost every time on a LAN.  I'd do ping 
-l 1500 -n 10 <ipaddr>   - in case the packet size makes a difference 
(which it could do if the WinServer had a flaky connection or network 
card that was stepping on the net - more likely to affect bigger packets). 

(for the hell of it, repeat that last step to the WinServer :-) 

Then if you're still stuck: 
    can you say a bit more about the script that does this ? 
    can you show the set of script lines involved ? 


-- 
Alex Tweedly       http://www.tweedly.net