libUrlFtpUploadFile - reuse open sockets?
revdev at pdslabs.net
Tue Apr 14 21:22:03 EDT 2009
Hi Jim B & Jim A,
Thanks for the replies.
Actually I'm using libUrlFtpUploadFile because some of the files are
movies (some > 100mb), so I don't want to use a blocking command.
The more I think about this, the more I believe it's a libUrl bug. If
socket reuse works for download (which I believe it does), it should
work for upload... Of course my argument is from a desire for the beauty
of symmetry without regard to what's possible - which is how many good
things come into being ;o)
I have a 2-part workaround:
### WORKAROUND PART 1
put 10 into xServerMax
-- I know the above number from experience;
-- would rather ask FTP server for max
-- but don't know an FTP command for it
libUrlSetFTPStopTime 1 -- set the socket timeout to 1 sec
### WORKAROUND PART1 - end
uploadMyFile tFirstLocalFile, tFirstServerPath
on uploadMyFile pLocalFile, pServerPath
on uploadEnded pUrl, pStatus
put pUrl & tab & pStatus & cr after fld "callbackParams"
put nextFileFromList() into p1
put nextServerPath() into p2
### WORKAROUND PART 2
repeat until (the number of lines in the openSockets < xServerMax)
wait 1 tick with messages
### WORKAROUND PART 2 - end
send ("uploadMyFile" && p1 & comma & p2) to me in 1 ticks
Jim Bufalini wrote:
> Hi Phil,
>> While using libUrlFtpUploadFile to upload a bunch of files to a server,
>> I find that libUrlFtpUploadFile opens a new socket for each upload.
>> using a callback message to start a new one when the current one
>> finishes, I get a "max number of connections" message back from the
>> server when the server's max number is reached. After this, the next
>> upload attempts fail due to max number of connections; then as the open
>> connections time out, new files can successfully upload again.
>> So... I want to know:
>> 1) Does FTP require a new socket for each upload?
>> 2) If not, how do I tell libUrlFtpUploadFile to reuse an existing open
>> socket for the next upload?
>> 3) Is there something else I'm missing? Am I making things more
>> complicated than they need to be? I have a nagging suspicion along this
>> Here's how my code is structured:
>> on uploadMyFile pLocalFile, pServerPath
>> libUrlFtpUploadFile pLocalFile,pServerPath,"uploadEnded"
>> end uploadMyFile
>> on uploadEnded pUrl, pStatus
>> put pUrl & tab & pStatus & cr after fld "callbackParams"
>> put nextFileFromList() into p1
>> put nextServerPath() into p2
>> send ("uploadMyFile" && p1 & comma & p2) to me in 6 ticks
>> end uploadEnded
> Since it doesn't appear that you are using the callback except to know the
> upload ended and assuming these files are not huge and you don't need to do
> anything else during the upload like show a progress bar or other
> processing, you can just use:
> Put "binfile:" before pLocalFile
> Put URL pLocalFile into URL pServerPath
> Unlike libUrlFtpUploadFile, a put URL is blocking, which means your
> upLoadMyFile command is paused until the upload completes. If there is an
> error, it will be returned in *the result* and you can handle your next
> logic in the same handler.
> I "believe" that because it's blocking, the socket is closed after the
> upload, but someone else can/will correct me on this if I am wrong. ;-)
> Aloha from Hawaii,
> Jim Bufalini
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
Professional Software Development
More information about the use-livecode