Presales support question

Hi there!

I am evaluating your library for purchase, and while it seems very robust (I am particlarly interested in that it implements compression), I am running into a couple of problems that I need to solve before I go ahead and spend the money.
My implementation is in, and I am using one computer withW2K for development, and another computer (also with W2K) for testing. All testing is being done against a Serv-U FTP server.

1) Whenever I try to upload a large file (more or less >150MB), I get a timeout error (lastError=ftpErrorTimeout) and the library disconnects. Is there any way around this? The following is an exerpt of my Serv-U log, for an upload of a file that is 336,054,666 bytes long (xxx detones edited text). The uploaded file is 317,904,346 bytes long:

[6] Sat 04Mar06 12:40:27 - (000006) 150 Opening ASCII mode data connection for /bin/ls.
[6] Sat 04Mar06 12:40:27 - (000006) 226 Transfer complete.
[2] Sat 04Mar06 12:40:28 - (000006) CWD /xxx/xxx/xxx/xxx/xxx
[6] Sat 04Mar06 12:40:28 - (000006) 250 Directory changed to /xxx/xxx/xxx/xxx/xxx
[2] Sat 04Mar06 12:40:28 - (000006) PWD
[6] Sat 04Mar06 12:40:28 - (000006) 257 "/xxx/xxx/xxx/xxx/xxx" is current directory.
[2] Sat 04Mar06 12:40:29 - (000006) PASV
[6] Sat 04Mar06 12:40:29 - (000006) 227 Entering Passive Mode (192,168,12,202,78,54)
[2] Sat 04Mar06 12:40:29 - (000006) STOR /xxx/xxx/xxx/xxx/xxx/Cam01_CAV_0329_DxO_01.psd
[4] Sat 04Mar06 12:40:29 - (000006) Receiving file e:\xxx\xxx\xxx\xxx\xxx\xxx\xxx\cam01_cav_0329_dxo_01.psd
[6] Sat 04Mar06 12:40:29 - (000006) 150 Opening BINARY mode data connection for Cam01_CAV_0329_DxO_01.psd.
[4] Sat 04Mar06 14:41:12 - (000006) Error receiving file e:\xxx\xxx\xxx\xxx\xxx\xxx\xxx\cam01_cav_0329_dxo_01.psd, aborting (42.9 kB/sec - 317904346 Bytes, command connection closed)
[6] Sat 04Mar06 14:41:12 - (000006) 426 Data connection closed, receive file Cam01_CAV_0329_DxO_01.psd aborted.
[5] Sat 04Mar06 14:41:12 - (000006) Closing connection for user XXX (02:02:39 connected)
[5] Sat 04Mar06 14:41:42 - (000007) Connected to (Local address
[6] Sat 04Mar06 14:41:42 - (000007) 220 Serv-U FTP Server v6.2 for WinSock ready...
[2] Sat 04Mar06 14:41:43 - (000007) USER Sync
[6] Sat 04Mar06 14:41:43 - (000007) 331 User name okay, need password.
[2] Sat 04Mar06 14:41:43 - (000007) PASS xxxxx
[5] Sat 04Mar06 14:41:43 - (000007) User xxx logged in
[6] Sat 04Mar06 14:41:43 - (000007) 230 User logged in, proceed.
[2] Sat 04Mar06 14:41:43 - (000007) SYST
[6] Sat 04Mar06 14:41:43 - (000007) 215 UNIX Type: L8
[2] Sat 04Mar06 14:41:43 - (000007) FEAT
[6] Sat 04Mar06 14:41:43 - (000007) 211-Extension supported
[6] Sat 04Mar06 14:41:43 - (000007) CLNT
[6] Sat 04Mar06 14:41:43 - (000007) MDTM
[6] Sat 04Mar06 14:41:43 - (000007) MDTM YYYYMMDDHHMMSS[+-TZ];filename
[6] Sat 04Mar06 14:41:43 - (000007) SIZE
[6] Sat 04Mar06 14:41:43 - (000007) SITE PSWD;EXEC;SET;INDEX;ZONE;CHMOD;MSG
[6] Sat 04Mar06 14:41:43 - (000007) REST STREAM
[6] Sat 04Mar06 14:41:43 - (000007) XCRC filename;start;end
[6] Sat 04Mar06 14:41:43 - (000007) MODE Z
[6] Sat 04Mar06 14:41:43 - (000007) MLST Type*;Size*;Create;Modify*;Win32.ea*;
[6] Sat 04Mar06 14:41:43 - (000007) 211 End

2) Everytime I log out from the testing mashine, I need to reinstall the library. Otherwise, I get an error when I try to connect to any FTP server (??). Once I reinstall the libray, everything works great. Any ideas??

3) This is not actually a problem, but I have to use the STAClass object because if I use MTA whenever I try to catch the 'ontransferprogress' event the library freezes (even if the event sub is empty). It freezes right after exiting the sub that catches the event.

>1 Transfer Timeouts
Transfer timeouts are normal and depending on your connection, the network configuration and the length of the transfer they may happen more likely than usual. In your case you have to handle them in the application you write. e.g. automatically resume broken transfers. You can get some hints from the Transfer Queue in SmartFTP how to implement this.

>2 dll register problem
This shouldn't be necessary. I suspect that the sfFTPLib.dll is not correctly registered anymore for some reasons. You can register the dll with the following command: regsvr32.exe sfFTPLib.dll
To ensure that the component is correctly registered you can do this every time your application is started.

>3 STA
When developing with VB.NET or any other languages under .NET use the FTPConnectionMTA class. Do not use the FTPConnectionSTA class.
Please try it again with the latest version from:
A problem has been fixed with the event handling and the FTPConnectionMTA class.



Thanks for the prompt reply. Your help is appreciated.

1) Today I downloaded the latest version of the lib (the link you posted seems to be broken), but it reads v (28 FEB), and in the change-log it seems there is a newer one somewhere.
Still, with this version, the MTA objects freezes the application when I catch the event. That problem does not seem to be solved.

2) Regarding timouts, I am currently using the FTP library from DART (I am planning to switch to yours if I can solve this problem), and I've never had any timouts. Also, the funny thing is that the timout occurs only when a couple of MB are left to be writen. I have total control over the FTP server and I am woundering if there is any(dirty) way of working around this issue without having to implement resume routines.

Thanks again for your help,


>1 MTA events
The .11 version is the one that fixed the problem with the events and MTA. Please test it with the VB.NET sample that comes with the library. The sample can be found in the Samples\VB.NET directory. This sample implements 3 event handlers (OnTransferProgress is one of them).

>2 Timeouts
Please post the transfer log doing the same file transfer when you use the DART library.
You can see in the log:
Error receiving file e:\xxx\xxx\xxx\xxx\xxx\xxx\xxx\cam01_cav_0329_dxo_01.psd, aborting (42.9 kB/sec - 317904346 Bytes, command connection closed)
that the reason the data transfer aborted is because the control connection got closed. A common problem is that NAT routers close the control connection during a data transfer because they believe that there is nothing happening.