Board index » delphi » Corruption w/TidFTP and Problems with .Connect(False)

Corruption w/TidFTP and Problems with .Connect(False)

Ok, I don't have any definitive answers yet but here's what I know,

Initially I was using .Connect(False) followed by a call to .Login and
was testing on a linux/unix server uploading and downloading some
simple .jpgs.  I'm using a TidFTP component inside a custom TThread
descendent that is configured for a single job and set running and is
freed immediately upon termination.  

The thread could upload the .jpg's correctly but all downloads were
highly corrupted.  This has really thrown me for a loop as the usage
of the TidFTP component is straight-forward and only about 7 or 8
lines total.  Most of the details on this problem are described in
another thread I started a few days ago titled "TidFTP."

After getting nowhere on understanding this corruption, I tested the
same basic procedure with the TidFTP component directly on a TForm in
the IDE designer and there was no corruption in the downloaded images.

So back to my threaded version using TidFTP I created a bare bones
project with a bare bones TThread descendent free of the extras in my
custom thread class.  The results were the same, each downloaded .jpg
was highly corrupted.  

I must say at this point the .jpg's are just simple line drawing of
faces on white.  In the corrupted download it is possible to see bits
and pieces of this image, enough to verify the component is finding
the correct file.

I then tested this against a local machine running IIS and without
change the downloads were perfect.  Since I'm running a local network
behind a gateway machine and using NAT all behind a single IP, and
despite the fact that it didn't make sense to me that this should be
problematic to my application, I ran the tests right from my server to
verify that the problem wasn't the data moving through my private
network's gateway to the public network.  The results, as I expected,
were the same and downloads from the remote unix ftp site were still
corrupted.

So to this point I'm using .Connect(False) and .Login but when
connecting to an IIS ftp site the images downloaded are fine, but when
connecting to a linux/unix site the images are corrupted.

Fairly at a loss for where to move next I tried to reduce even further
my manipulation of TidFTP.  To this point I had been purposely calling
Connect without the auto-login followed by the call to Login, so I
changed this to allow the auto-login and removed the call to .Login.
At this point the downloads were perfect and without corruption.

So where does this leave me?

1) When testing the TidFTP component on a form I set most of the
required properties in the OI including the username and password and
allowed the component to auto-login so the results of this test do not
contradict the problems I'm seeing.  To investigate further one might
duplicate this test but not allow the component to auto-login and see
if the images are corrupt.  I've not done this.

2) When testing the TidFTP component in a custom TThread class if you
don't allow the component to auto-login downloads from my linux server
are corrupted but from my IIS site are not.  

3)  In the same thread class, if you allow auto-login with connect
downloads from both server types are successful and without error.

Is there something in connecting to a linux/unix variety server that
I'm not configuring correctly when dynamically creating and
initializing the TidFTP component?  Looking through the list of
properties and methods I'm not seeing any additional services or
configurable options that I may have missed.

Why would the component behave differently when not allowing
auto-login depending on the server type?

The bare bones TThread descendent and test exe's, one for
Connect(False) the other for Connect, can be found here,

  <http://www.digitalsurvival.net/FTP Download Debug.zip>

They are hard-coded to connect to the linux server and download a
single .jpg.  If anyone takes a look at these I'd appreciate
confirmation on the status and corruption of the two images.  Be
advised, the two versions still download the image as the same name to
they will overwrite the last attempt.  

To the Indy team, either I'm missing something in configuring the
TidFTP component or there's a bug here.  I don't see why
Connect(False) should have any impact on transferring data.  If I'm
really missing something I'd really appreciate being set straight.
I've approached using the Indy components very strictly as a user.  I
shouldn't have to become a network component expert to use these
components, thus, one way or another my experiences described here and
my example should indicate more work needs to be done somewhere.

Thanks for any help or thoughts,

Jim

------------------------------------------------------------------------
 Jim Burns, <mailto:jim at Technology Dynamics dot com>
   Technology Dynamics
   Pearland, Texas  USA
   281 485-0410

 

Re:Corruption w/TidFTP and Problems with .Connect(False)


Quote
On Fri, 14 Mar 2003 14:20:25 -0600,  wrote:
> [snip]

Here's some code for you to look at:

    if AAutoLogin then begin
      Login;
      DoAfterLogin;
      //Fast track is set only one time per connection and no more, even
      //with REINIT
      if TryNATFastTrack then
      begin
        DoTryNATFastTrack;
      end;
      SendTransferType;
      // OpenVMS 7.1 replies with 200 instead of 215 - What does the RFC say about this?
     // if SendCmd('SYST', [200, 215, 500]) = 500 then begin  {Do not translate}
     //Do not fault if SYST was not understood by the server.  Novel Netware FTP
     //may not understand SYST.
     if SendCmd('SYST') = 500 then begin  {Do not translate}
        FSystemDesc := RSFTPUnknownHost;
      end else begin
        FSystemDesc := LastCmdResult.Text[0];
      end;
      DoStatus(ftpReady, [RSFTPStatusReady]);
    end;

All of that is skipped when not doing auto-login, maybe you should try
some of that (NATFastTrack, SendTransferType) after .Login

johannes

Re:Corruption w/TidFTP and Problems with .Connect(False)


Quote
>    if AAutoLogin then begin
>      Login;
>      DoAfterLogin;
>      //Fast track is set only one time per connection and no more, even
>      //with REINIT
>      if TryNATFastTrack then
>      begin
>        DoTryNATFastTrack;
>      end;
>      SendTransferType;
>      // OpenVMS 7.1 replies with 200 instead of 215 - What does the RFC say about this?
>     // if SendCmd('SYST', [200, 215, 500]) = 500 then begin  {Do not translate}
>     //Do not fault if SYST was not understood by the server.  Novel Netware FTP
>     //may not understand SYST.
>     if SendCmd('SYST') = 500 then begin  {Do not translate}
>        FSystemDesc := RSFTPUnknownHost;
>      end else begin
>        FSystemDesc := LastCmdResult.Text[0];
>      end;
>      DoStatus(ftpReady, [RSFTPStatusReady]);
>    end;

I found TidFTP.Connect(...) in idFTP.pas and it looks alot like this,
but there are no references to TryNATFastTrack so I'm clueless there.
(Indy 9 w/D7)

The wierd thing is that if you look at .Login, which you would
certainly call after a .Connect(False), it /doesn't/ appear to so the
same thing that .Connect does after it's own call to .Login.  

I'm not the TidFTP expert..... :)

Still, I have called

      ctrlFTP.TransferType := ftBinary;

after .Login but this has no discernable effect on the downloads.

Jim

------------------------------------------------------------------------
 Jim Burns, <mailto:jim at Technology Dynamics dot com>
   Technology Dynamics
   Pearland, Texas  USA
   281 485-0410

Re:Corruption w/TidFTP and Problems with .Connect(False)


Quote
> I found TidFTP.Connect(...) in idFTP.pas and it looks alot like this,
> but there are no references to TryNATFastTrack so I'm clueless there.
> (Indy 9 w/D7)

Thats part of Indy 10 now, sorry.

Quote
> The wierd thing is that if you look at .Login, which you would
> certainly call after a .Connect(False), it /doesn't/ appear to so the
> same thing that .Connect does after it's own call to .Login.  

That could be the problem :)
Could you - for the record - try calling all that code?
I'm more thinking of thread issues here though.

johannes

Re:Corruption w/TidFTP and Problems with .Connect(False)


Quote
"Johannes Berg" <n...@johannes.sipsolutions.de> wrote in message

news:pan.2003.03.14.21.28.54.288794@johannes.sipsolutions.de...
| Thats part of Indy 10 now, sorry.
|

HEY, that is secret <g>

| johannes

the problem is in the SendTransferType, it is only send when AAutoLogin
=true.
when AAutoLogin{*word*254}is not send in .login. this is fixed by moving it from
.connect to .login.

Bas

Other Threads