tcllib ::ftp::open connection delay



Hi,

This topic was started months ago. I replied using google, but my reply doesn't seem to exist. I'm starting a new thread.

Below is the reply I got from Alex Ferrieux:

On Mar 22, 3:17 am, James <james.e.stew...@xxxxxxxxx> wrote:

I've got a Tcl App that runs on a Windows box, and it connects to a
Linux PC via FTP to transfer a few files automagically.

Reverse DNS lookups are turned off in the Linux proftpd server.

The command ::ftp::Open host user passwd seems to pause for about 15
seconds.

I've straced the Linux proftpd process and see a 15 second delay from
the time the server sends the welcome message to when the Tcl app on
windows replies with a USER blah.

I've also used tcpdump to see the FTP packets and timing, and the
windows Tcl app Acks the welcome message, then there's a 15 second
delay before Tcl sends the USER blah command.


Interesting. Very good report, by the way !

Is this a TCP_NODELAY or socket flush issue? I've looked through the
tcllib ftp.tcl code and don't see where a delay of this magnitude
would appear.


TCP_NODELAY would not exceed 200ms. Flush issue, quite possibly, don't
know this code, but... it's quite heavily used, such an obvious
mistake should have been spotted earlier... Hm.


The native windows FTP client can connect as fast as I can type the
commands.

Can anyone offer some advice?


The tough part is "Windows", of course. Any hope to run the client in
Linux and strace it ? Be sure to use the same Tcl (same threadedness
of build) and ::ftp version. If not, I'd try random shots:

network level:

- tcpdump/wireshark on the windows side (just in case of unseen
packet loss)
- also look for non-tcp packets, esp. DNS, in case the client
code does a [fconfigure -peer/sockname] and tries to rev-dns its own
host's or the server's IP, just for fun.


script level:

- grab a debug build of Tcl, set ::tcl_traceExec to 1 or 2, and
watch.
- if not possible, do the same by setting enterstep exec traces
on all procs, after loading ::ftp.

And by all means, please report back once you find the answer. I'm
puzzled !

-Alex

Well, I've finally got back to looking at this, and captured two network packet dumps, one using TCL FTP, and the other using Windows command line FTP client.

Windows client first;

11:59:05.678654 IP windows.1152 > linux.21: S 4170842005:4170842005(0) win 65535 <mss 1460,nop,nop,sackOK>
11:59:05.678989 IP linux.21 > windows.1152: S 42030754:42030754(0) ack 4170842006 win 5840 <mss 1460,nop,nop,sackOK>
11:59:05.679004 IP windows.1152 > linux.21: . ack 1 win 65535
11:59:05.680514 IP linux.21 > windows.1152: P 1:63(62) ack 1 win 5840
11:59:05.881403 IP windows.1152 > linux.21: . ack 63 win 65473
11:59:06.009874 arp who-has 192.168.1.1 tell windows
11:59:06.010818 arp reply 192.168.1.1 is-at 00:26:f2:28:c1:a2 (oui Unknown)
11:59:06.010823 IP windows.49925 > 192.168.1.1.53: 6891+ PTR? 131.1.168.192.in-addr.arpa. (44)
11:59:07.006385 IP windows.49925 > 192.168.1.1.53: 6891+ PTR? 131.1.168.192.in-addr.arpa. (44)
11:59:08.006366 IP windows.49925 > 192.168.1.1.53: 6891+ PTR? 131.1.168.192.in-addr.arpa. (44)
11:59:08.997602 IP windows.1152 > linux.21: P 1:11(10) ack 63 win 65473
11:59:08.997879 IP linux.21 > windows.1152: . ack 11 win 5840

And now the TCL FTP lib trace;

11:55:13.175199 IP windows.1128 > linux.21: S 3708272606:3708272606(0) win 65535 <mss 1460,nop,nop,sackOK>
11:55:13.175613 IP linux.21 > windows.1128: S 704052802:704052802(0) ack 3708272607 win 5840 <mss 1460,nop,nop,sackOK>
11:55:13.175627 IP windows.1128 > linux.21: . ack 1 win 65535
11:55:13.175798 IP windows.58202 > 192.168.1.1.53: 46271+ PTR? 131.1.168.192.in-addr.arpa. (44)
11:55:13.177127 IP linux.21 > windows.1128: P 1:63(62) ack 1 win 5840
11:55:13.235137 IP windows.1128 > linux.21: . ack 63 win 65473
11:55:13.972835 IP windows.64156 > 192.168.1.1.53: 60345+ PTR? 131.1.168.192.in-addr.arpa. (44)
11:55:14.172615 IP windows.58202 > 192.168.1.1.53: 46271+ PTR? 131.1.168.192.in-addr.arpa. (44)
11:55:14.969474 IP windows.64156 > 192.168.1.1.53: 60345+ PTR? 131.1.168.192.in-addr.arpa. (44)
11:55:15.172594 IP windows.58202 > 192.168.1.1.53: 46271+ PTR? 131.1.168.192.in-addr.arpa. (44)
11:55:15.969483 IP windows.64156 > 192.168.1.1.53: 60345+ PTR? 131.1.168.192.in-addr.arpa. (44)
11:55:17.172565 IP windows.58202 > 192.168.1.1.53: 46271+ PTR? 131.1.168.192.in-addr.arpa. (44)
11:55:17.969414 IP windows.64156 > 192.168.1.1.53: 60345+ PTR? 131.1.168.192.in-addr.arpa. (44)
11:55:21.172487 IP windows.58202 > 192.168.1.1.53: 46271+ PTR? 131.1.168.192.in-addr.arpa. (44)
11:55:21.969338 IP windows.64156 > 192.168.1.1.53: 60345+ PTR? 131.1.168.192.in-addr.arpa. (44)
11:55:28.172475 IP windows.137 > linux.137: UDP, length 50
11:55:28.172787 IP linux.137 > windows.137: UDP, length 229
11:55:28.172801 IP linux.138 > 192.168.1.255.138: UDP, length 234
11:55:28.172806 IP linux.138 > 192.168.1.255.138: UDP, length 211
11:55:28.174387 IP windows.1128 > linux.21: P 1:11(10) ack 63 win 65473

As you can see, it takes about 15 seconds using TCL FTP, but only a few seconds using Windows FTP client.

The difference seems to be a heap of PTR reverse DNS messages, or some such. I'm no networking guru, so please correct me if I'm wrong.

Is there some setting that can be twiddled?

If the router that connects the Windows and Linux machines is connected to the WAN, the reverse DNS happens quickly. It seems though, that Windows caches something about the reverse DNS results, because if the router is subsequently reset without a WAN connection, the FTP open command still executes quickly. Only a different router with no WAN connection seems to make Windows go slow again.

Any thoughts?

Regards,
James.
.