🚀 go-pugleaf

Hi Remy,

The reason I didn't try before decreasing the size of the blocks. I thought
that by sending tinier blocks will make the program to wait for more
responses from the server, and it could be even worse.
But after Mark adviced me to decrease the size to 2048 it worked perfectly.
Yesterday I didn't have time to do extensive testing, but I managed to
upload all the images from the folder for the first time.
Even if you say that the size of the blocks has nothing to do with it, I am
not so sure about that. I think IdFTP uploads the file to the server in
blocks of a preset size, it doesn't have to do with how the bytes are stored
in the memory. (I apologise for not agreeing with you on this matter,
considering I know nothing about how IdFTP works and you know so much about
everything :-) )

I will continue doing tests tonight (with different block sizes) and I will
let you know what is going on. But I think the size of the blocks counts.

Regards,
Nicolae



"Remy Lebeau (TeamB)" <gambit47.no.spam@no.spam.yahoo.com> wrote in message
news:40f6cbe5$1@newsgroups.borland.com...
>
> "Mark Jacobs" <markj atty critical dotty co dotty uk> wrote in message
> news:40f6a51a@newsgroups.borland.com...
>
> > It may be that your block upload size is too big. I am not
> > well-versed in the FTP protocol, but in TCP/IP you are
> > best advised to keep blocks at around 2048 bytes tops.
>
> That has nothing to do with it.  Block size does not matter to Indy at
all,
> since every byte received is buffered in memory regardless of the block
size
> used.  Indy reads however many bytes are actually available in the socket.
> If Put() is waiting for a response from the server that never comes, then
> the server is not sending the response to begin with, or it is somehow
> getting lost during transmission altogether.
>
>
> Gambit
>
>