Here is from our experience. I can't explain why this is happening,
but repeated tests show that it does.
1) Using the blocking form (put url xx into url yy), we experienced
that a foreground file transfer that might take 30 seconds would be
effected by a pendingmessage file transfer scheduled to occur
sometime during the time frame of that foreground transfer
2) Using the non-blocking form (libURLFTPupload or download), in
concert with a "wait until messages" line thereafter, would also be
effected by pending messages.
Canceling all pending messages, then resending them after the
transfers, helped a great deal. Keep in mind all of these transfers
are occurring under strained wireless conditions outdoors over a
distance of up to 500 feet, with a signal that can drop briefly at
any time. We have to structure all of our transfers with considerable
robustness to repeat the transfer over and over again until it is
successful.
We've also discovered that the built-in Rev file transferring methods
(both blocking and non-blocking) cannot simply be immediately
repeated if one fails during a transfer attempt... at least not with
Rumpus ftp server software and OSX. The server (under its default
settings) rejects subsequent attempts unless we unload the url, send
a QUIT command, and wait some period of time before starting the next
attempt. We're still trying to come up with a reliable approach to
guarantee any downloads or uploads work every time, even if it takes
five attempts.
Richard
On Mar 5, 2007, at 10:46 AM, Dave Cragg wrote:
On 5 Mar 2007, at 16:25, Richard Gaskin wrote:
There's a blocking form for uploading and downloading available in
libURL, and in the last several versions includes callbacks so one
can update a progress indicator or do other minor housekeeping.
Would that help your situation?
I haven't quite grasped Richard's problem of the pendingMessages.
But I doubt it would make a difference whether using "blocking" or
non-blocking url routines. The so-called blocking routines are only
"script-blocking". i.e. they block the currently executing handler,
but will allow other asynchronous activity. (For example, clicking
on an active button during a download, or presumably executing
anything put on the pendingMessages queue before the "blocking"
routine was called.)
Generally, anything on the pendingMessages queue will execute
during an FTP file transfer, if it's due to be run at that time.
Depending on the message, it might interfere with the transfer. For
example, a long repeat that exceeds the socketTimeout interval.
Cheers
Dave
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution