Pendingmessages

[Richard Miller]

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 at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your  
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution