Pendingmessages

Richard Miller wow at together.net
Tue Mar 6 08:55:11 EST 2007


One of the problems we've encountered is that in the pending  
messages, we need to regularly check a directory on the server. That  
procedure is, I believe, always a blocking call. I haven't figured  
out a way to do it as a non-blocking call. So that short process  
itself interferes with current blocking FTP transfers (unless I  
cancel that pending message and re-schedule it for immediately after  
the current transfer).

Another issue we've encountered is that transferring very small text  
files (a line or two of text) via the wireless connection seems less  
stable and more difficult to verify when using the non-blocking ftp  
calls rather than a simple "put url xx into url yy" form. I've also  
found it difficult to reliably compare file sizes of the original  
file to the received file for these very small files.

Tied into this is that getting a directory from the server is  
obviously just as prone to failure as getting any file from the  
server since it's all a wireless call either way and the signal could  
drop at any time. What's the most reliable way to verify that the  
directory call went through correctly? Seems the only way is to check  
"the result", since the contents of a given directory could be empty  
to begin with (meaning we can't compare the value that comes back to  
see if it is empty, since it might have been empty to start with).  
It's unclear of the issues we are encountering in repeatedly trying  
to get a directory if prior attempts fail. Can/should a directory ftp  
call be unloaded (i.e. via unload URL) before trying a second time?

Thanks for the feedback below Dave.

Richard



On Mar 6, 2007, at 6:03 AM, Dave Cragg wrote:

>
> On 6 Mar 2007, at 11:29, Richard Miller wrote:
>
>> 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
>
>
> I see a potential problem here, but it depends what you're doing in  
> the file transfer pendingMessage handler. When using blocking calls  
> (get url, put ... into url) only one transfer can be processed at a  
> time by libUrl. If you attempt to start another transfer before the  
> previous one completes, you will get an error in the result.  
> Depending on how your file transfer handler handles errors (Can it  
> dstinguish between an error in a currently uploading transfer and  
> one that has been called before the previous one completes?) it  
> could get messy.
>
> I don't think using the pendingMessages queue to schedule blocking  
> transfers is the best approach. Typically, you would wait until one  
> transfer completes, and then start the next one.
>
> If you know the files to be transferred when you start the  
> procedure, I would do something like this (error checking points  
> only indicated):
>
> on fileTransfer pFileList
>
>  repeat for each line tFile in pFileList
>     put <whatever> into tUrl ## your url setting routine here
>     put url ("binfile:" & pFile) into tData
>     ## check the result here in case of local file error
>     repeat 5 times ## or however many times you want to try
>        put false into tFailed
>        put tData into url tUrl
>        if the result is empty then
>          exit repeat
>        else
>          put true into tFailed
>        end if
>      end repeat
>      if tFailed then
>         ## perhaps record the file name
>         ## and show a list of failed uploads later
>      end if
>  end repeat
>
> end fileTransfer
>
> If you don't know the files in advance, then I'd add them to a  
> queue (perhaps a custom property or global or script local  
> variable. Then have the transfer routine check the queue when it  
> finshes a transfer.
>
> local sFileQ
>
> on startTransferRoutine ## called only once, perhas at startup
>      send tranferFile to me in 0 milliseconds
> end startTransferRoutine
>
> on qFile pFile ## adds file to queue
>     if pFile <> empty then
> 	put line 1 of pFile & cr after sFileQ
>     end if
> end qFile
>
> on transferFile
>   if the number of lines of sFileQ > 0 then
>     repeat until tFile <> empty
>       put line 1 of sFileQ into tFile
>       delete line 1 of tFile
>     end repeat
>     put <whatever> into tUrl ## your url setting routine here
>     put url ("binfile:" & pFile) into tData
>     ## check the result here in case of local file error
>     repeat 5 times ## or however many times you want to try
>        put false into tFailed
>        put tData into url tUrl
>        if the result is empty then
>          exit repeat
>        else
>          put true into tFailed
>        end if
>      end repeat
>      if tFailed then
>         ## perhaps record the file name
>         ## and show a list of failed uploads later
>      end if
>   end if
>   send transferFile to me in 1000 milliseconds
> end transferFile
>
>
>> The server (under its default settings) rejects subsequent  
>> attempts unless we unload the url,
>
> For non-blocking calls, you must unload the url, even after an error.
>
>
>> send a QUIT command, and wait some period of time before starting  
>> the next attempt.
>
> That doesn't sound too good.
>
> 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




More information about the use-livecode mailing list