LiveCode Forums.

Has anyone (using 4.6) experienced 60 second delays when using the URL keyword in this form: I have several Macs running older versions of Revolution and performing literally thousands of FTP downloads a day, usually a few tens of bytes per download, and they take 100 milliseconds or less. I have introduced a new Intel Mac running LiveCode 4.6 into the mix, and most of the time it can FTP in under 100 msecs, but it can also take 60100 millisecs on occasion. There is no rhyme or reason to when this delay shows up, from what I can see, but it always appears to be around 60 seconds. Sometimes it happens twice a day, sometimes it happens ten times an hour. The FTP server can be either another Mac or a local network storage appliance.

Any thoughts? Thanks, Ivar

Hi MacIvar,

I vaguely remember an update related to this issue. Have you tested 4.6.1?

Kind regards,

Mark

Mark,

Haven't tried 4.6.1 but I certainly will, thanks!

-Ivar

Why is it faster to download a file through FTP vs Terminal Services? A 5 GB file seems to be a lot faster download as compared to using remote desktop to copy the remote file to my local drive. I know FTP is built for file transfering, but what exactly makes it so much faster?
___________________________
market samurai ~ marketsamurai

Two weeks after switching to 4.6.1 here are some results taken from the two Macs that do the most FTP'ing around here...

The rate of 60 second delays experienced during FTP, expressed as number of delays per 1000 transfers, are -
using 4.6 : 3.048
using 4.6.1: 3.905

In other words, it got worse. Not to say that the upgrade is the cause, something else in the network environment may have changed, but if there was a specific fix to address this problem in 4.6.1 it didn't work for me.

<sigh>

Most likely this is a DNS problem, or a problem with the way LiveCode handles DNS. The approach was changed with 4.6, so it might be worthwhile to check if the same problem exists in an older version.

As for fixing, and assuming LC has faulty DNS code somewhere,maybe a mail to support AT runrev dot com could help make them aware of a general issue.

For an immediate workaround, you could try to do the lookup manually, then only using the ip in your ftp calls. The following functions will be helpfull with that:

the dnsServers
the hostAddressToName
the hostNameToAddress

Obviously this won't help if the problem is not in the DNS code, but the libURL ftp calls themselves.

This is valuable insight - my Macs are on an isolated network without a DNS, all IP addressing is done with dotted-quad numbers. I did some quick testing on 4.5.3 and the problem exists there too, with at least the same results if not worse.

I'll send a note off to the support folks. Thanks BvG!

-Ivar

Dear BvG,

I’m also experiencing these delays, and would like to try your suggestion using hostNameToAddress. But I can’t figure out how to do it when my ftp command addresses directories and subdirectories. For example, suppose my original ftp command is:

put URL “ftp://signonname:password@www.address.c ... lename.txt" into StringName

and I use hostNameToAddress to determine that http://www.myaddress.com is 77.777.777.77. What part of my “put” command gets the 77.777.777.77? I tried replacing just the “ww.myaddress.com”, but that does not work.

Sincerely,

Steve Alessi

Hi Steve,

You use the domain name only:
Kind regards,

Mark

Sorry, I did not ask my question clearly enough. I understand how to get the I.P. number using
put hostnametoaddress("domain.com").

My question is, once I have the I.P. number, what does it replace within a command like the following:

put URL “ftp://signonname:password@www.address.c ... lename.txt" into StringName

(Isn't that the reason for getting the actual I.P. number?)

Steve Alessi

Hi Steve,

OK, I get it. You replace the first part, www.domain.com, with the IP address. You will always need to use the actual path to the directory, i.e. www.domain.com/sub1/sub2/file.php and not sub1.domain.com/sub2. If you have a shared server, this solution may not work at all.

Best,

Mark