Binary GET failure

Question

I've written an app to get a group of directories and their files from a unix (QNX) system and dump them on the C drive of a Windows PC.

The application works great on my development system but when I deploy it to another computer the FTP transfer locks up (always on the same file) during a file GET. The last entry in the log is where the FTP fails.

Is there something I am missing? I have deployed the following:-

edtftpnet-1.2.2.dll
edtftpnet-1.2.2.pdb
MY_APPLICATION.exe
MY_APPLICATION.pdb
nunit.framework.dll



The last few lines of the log file:-


DEBUG [EnterpriseDT.Net.Ftp.FTPControlSocket] 17 Oct 2005 15:39:37.282 : 150 Opening BINARY mode data connection for file list.
DEBUG [EnterpriseDT.Net.Ftp.FTPControlSocket] 17 Oct 2005 15:39:37.462 : 226 Transfer complete.
DEBUG [EnterpriseDT.Net.Ftp.FTPClient] 17 Oct 2005 15:39:37.462 : Found 5 listing lines
DEBUG [EnterpriseDT.Net.Ftp.FTPControlSocket] 17 Oct 2005 15:39:37.462 : ---> PORT 172,21,50,170,5,92
DEBUG [EnterpriseDT.Net.Ftp.FTPControlSocket] 17 Oct 2005 15:39:37.472 : 200 PORT command successful.
DEBUG [EnterpriseDT.Net.Ftp.FTPControlSocket] 17 Oct 2005 15:39:37.472 : ---> RETR patient.dat
DEBUG [EnterpriseDT.Net.Ftp.FTPControlSocket] 17 Oct 2005 15:39:37.502 : 150 Opening BINARY mode data connection for patient.dat (450 bytes).
DEBUG [EnterpriseDT.Net.Ftp.FTPClient] 17 Oct 2005 15:39:37.532 : Transferred 450 bytes from remote host
DEBUG [EnterpriseDT.Net.Ftp.FTPControlSocket] 17 Oct 2005 15:39:37.663 : 226 Transfer complete.
DEBUG [EnterpriseDT.Net.Ftp.FTPControlSocket] 17 Oct 2005 15:39:37.663 : ---> PORT 172,21,50,170,5,93
DEBUG [EnterpriseDT.Net.Ftp.FTPControlSocket] 17 Oct 2005 15:39:37.703 : 200 PORT command successful.
DEBUG [EnterpriseDT.Net.Ftp.FTPControlSocket] 17 Oct 2005 15:39:37.703 : ---> RETR 427258cf.abp
DEBUG [EnterpriseDT.Net.Ftp.FTPControlSocket] 17 Oct 2005 15:39:37.743 : 150 Opening BINARY mode data connection for 427258cf.abp (1068 bytes).
DEBUG [EnterpriseDT.Net.Ftp.FTPClient] 17 Oct 2005 15:39:37.773 : Transferred 1068 bytes from remote host
DEBUG [EnterpriseDT.Net.Ftp.FTPControlSocket] 17 Oct 2005 15:39:37.863 : 226 Transfer complete.
DEBUG [EnterpriseDT.Net.Ftp.FTPControlSocket] 17 Oct 2005 15:39:37.863 : ---> PORT 172,21,50,170,5,94
DEBUG [EnterpriseDT.Net.Ftp.FTPControlSocket] 17 Oct 2005 15:39:37.873 : 200 PORT command successful.
DEBUG [EnterpriseDT.Net.Ftp.FTPControlSocket] 17 Oct 2005 15:39:37.873 : ---> RETR 428d9f1d.exc
DEBUG [EnterpriseDT.Net.Ftp.FTPControlSocket] 17 Oct 2005 15:39:37.903 : 150 Opening BINARY mode data connection for 428d9f1d.exc (1635 bytes).

Cheers,


Tim.

Answer 1

Can you get this file via command line FTP without any problems to the same directory with the same credentials?

Answer 2

I've noticed that the FTP does not totally lockup, but has a timeout after approx 9 min. The last part of the logfile looks like:-

INFO [Huntleigh.FTPclient.PatientTransfer] 17 Oct 2005 16:42:27.007 : TIM getting file 427258cf.abp to \Assisttmpftp\print000\427258cf.abp
DEBUG [EnterpriseDT.Net.Ftp.FTPControlSocket] 17 Oct 2005 16:42:27.007 : ---> PORT 172,21,50,170,5,198
DEBUG [EnterpriseDT.Net.Ftp.FTPControlSocket] 17 Oct 2005 16:42:27.017 : 200 PORT command successful.
DEBUG [EnterpriseDT.Net.Ftp.FTPControlSocket] 17 Oct 2005 16:42:27.017 : ---> RETR 427258cf.abp
DEBUG [EnterpriseDT.Net.Ftp.FTPControlSocket] 17 Oct 2005 16:42:27.048 : 150 Opening BINARY mode data connection for 427258cf.abp (1068 bytes).
DEBUG [EnterpriseDT.Net.Ftp.FTPClient] 17 Oct 2005 16:42:27.088 : Transferred 1068 bytes from remote host
DEBUG [EnterpriseDT.Net.Ftp.FTPControlSocket] 17 Oct 2005 16:42:27.208 : 226 Transfer complete.
INFO [Huntleigh.FTPclient.PatientTransfer] 17 Oct 2005 16:42:27.208 : TIM getting file 428d9f1d.exc to \Assisttmpftp\print000\428d9f1d.exc
DEBUG [EnterpriseDT.Net.Ftp.FTPControlSocket] 17 Oct 2005 16:42:27.208 : ---> PORT 172,21,50,170,5,199
DEBUG [EnterpriseDT.Net.Ftp.FTPControlSocket] 17 Oct 2005 16:42:27.218 : 200 PORT command successful.
DEBUG [EnterpriseDT.Net.Ftp.FTPControlSocket] 17 Oct 2005 16:42:27.218 : ---> RETR 428d9f1d.exc
DEBUG [EnterpriseDT.Net.Ftp.FTPControlSocket] 17 Oct 2005 16:42:27.298 : 150 Opening BINARY mode data connection for 428d9f1d.exc (1635 bytes).
ERROR [EnterpriseDT.Net.Ftp.FTPClient] 17 Oct 2005 16:51:47.492 : Caught exception : Unable to read data from the transport connection.
at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)
at System.IO.BinaryReader.Read(Byte[] buffer, Int32 index, Int32 count)
at EnterpriseDT.Net.Ftp.FTPClient.ReadChunk(BinaryReader input, Byte[] chunk, Int32 chunksize)
at EnterpriseDT.Net.Ftp.FTPClient.GetBinary(String localPath, String remoteFile)
INFO [Huntleigh.FTPclient.PatientTransfer] 17 Oct 2005 16:51:47.793 : TIM file download failed
INFO [Huntleigh.FTPclient.PatientTransfer] 17 Oct 2005 16:51:47.793 : TIM getting file 428df610.dop to \Assisttmpftp\print000\428df610.dop
DEBUG [EnterpriseDT.Net.Ftp.FTPControlSocket] 17 Oct 2005 16:51:47.793 : ---> PORT 172,21,50,170,5,223
DEBUG [EnterpriseDT.Net.Ftp.FTPControlSocket] 17 Oct 2005 16:51:47.793 : 226 Transfer complete.
INFO [Huntleigh.FTPclient.PatientTransfer] 17 Oct 2005 16:51:47.803 : TIM file download failed
INFO [Huntleigh.FTPclient.PatientTransfer] 17 Oct 2005 16:51:47.803 : TIM getting file 3f38d799.ctg to \Assisttmpftp\print000\3f38d799.ctg
DEBUG [EnterpriseDT.Net.Ftp.FTPControlSocket] 17 Oct 2005 16:51:47.803 : ---> PORT 172,21,50,170,5,224
DEBUG [EnterpriseDT.Net.Ftp.FTPControlSocket] 17 Oct 2005 16:51:47.803 : 200 PORT command successful.
DEBUG [EnterpriseDT.Net.Ftp.FTPControlSocket] 17 Oct 2005 16:51:47.803 : ---> RETR 3f38d799.ctg
DEBUG [EnterpriseDT.Net.Ftp.FTPControlSocket] 17 Oct 2005 16:51:47.813 : 200 PORT command successful.
INFO [Huntleigh.FTPclient.PatientTransfer] 17 Oct 2005 16:51:47.813 : TIM file download failed
DEBUG [EnterpriseDT.Net.Ftp.FTPControlSocket] 17 Oct 2005 16:51:47.813 : ---> CWD /pma/patient/smith000
DEBUG [EnterpriseDT.Net.Ftp.FTPControlSocket] 17 Oct 2005 16:51:47.853 : 425 Can't build data connection: Connection refused.
INFO [Huntleigh.FTPclient.PatientTransfer] 17 Oct 2005 16:51:47.853 : TIM not directory /pma/patient/smith000
DEBUG [EnterpriseDT.Net.Ftp.FTPControlSocket] 17 Oct 2005 16:51:47.853 : ---> CWD /pma/patient/willi000
DEBUG [EnterpriseDT.Net.Ftp.FTPControlSocket] 17 Oct 2005 16:51:47.863 : 250 CWD command successful.
DEBUG [EnterpriseDT.Net.Ftp.FTPControlSocket] 17 Oct 2005 16:51:47.863 : ---> PORT 172,21,50,170,5,225
DEBUG [EnterpriseDT.Net.Ftp.FTPControlSocket] 17 Oct 2005 16:51:47.873 : 250 CWD command successful.
INFO [Huntleigh.FTPclient.PatientTransfer] 17 Oct 2005 16:51:47.873 : TIM not directory /pma/patient/willi000
DEBUG [EnterpriseDT.Net.Ftp.FTPControlSocket] 17 Oct 2005 16:51:47.873 : ---> CWD /pma/patient/notadirectory
DEBUG [EnterpriseDT.Net.Ftp.FTPControlSocket] 17 Oct 2005 16:51:47.893 : 200 PORT command successful.
INFO [Huntleigh.FTPclient.PatientTransfer] 17 Oct 2005 16:51:47.893 : TIM not directory /pma/patient/notadirectory
INFO [Huntleigh.FTPclient.PatientTransfer] 17 Oct 2005 16:51:47.893 : END OF LOG


As a side note, I can ftp to the server OK by using the windows ftp client.
I.e. There is no problem with the file 428d9f1d.exc


Cheers,


Tim

Answer 3

Yes,

Command line FTP works great.

And my application works great from my development computer.

This problem is only on computers that I deploy the app.

Cheers,


Tim

Answer 4

Are you transferring many files? Each data transfer uses a new socket, and it looks like you are running out of sockets on your client (as using PORT creates a socket on the client).

Answer 5

I'm only getting about 30-40 files.

Is there a way of re-using the the sockets?

If not, how do I set the maximum sockets the PC uses?


Many thanks for your time on this issue,



Tim

Answer 6

Sorry to bump this.

Can you support guys think of anything else I can try to resolve this issue?
I'm at a loss.

I've tried active and passive modes, which made no difference, nor does ASCII and BINARY mode.

Any workarounds you can suggest?

What about doing a login/connect/disconnect before and after each file?


Cheers,


Tim

Answer 7

Typically, with FTP you have to either increase the number of sockets available or slow down the transfers. For example, our code for recursively transferring directories permits a sleep to be done every n transfers.

When sockets are closed, they go into a TIME_WAIT state for 2 minutes, typically. If you use netstat -a you will see this. They only get cleaned up after TIME_WAIT expires which is why you run out of sockets.

You can reduce the TIME_WAIT period if you wish (be careful, it is there to prevent TCP packet duplication), on Windows see the TcpTimedWaitDelay registry value.

See

http://msdn.microsoft.com/library/defau ... _delay.asp

for some more details. You can also increase the number of available sockets.

Sorry to bump this.

Can you support guys think of anything else I can try to resolve this issue?
I'm at a loss.

I've tried active and passive modes, which made no difference, nor does ASCII and BINARY mode.

Any workarounds you can suggest?

What about doing a login/connect/disconnect before and after each file?


Cheers,


Tim

Answer 8

For example, our code for recursively transferring directories permits a sleep to be done every n transfers.

Is this code public available? If so, where can I find it?
Perhaps I can investigate my problem cases with it.

Thanks in advance.

Kind regards,

David van Leerdam

Answer 9

Sorry, this code is part of edtFTPnet/PRO

http://www.enterprisedt.com/products/ed ... rview.html

We have to keep a few goodies for that product, otherwise there wouldn't be an edtFTPnet!

For example, our code for recursively transferring directories permits a sleep to be done every n transfers.

Is this code public available? If so, where can I find it?
Perhaps I can investigate my problem cases with it.

Thanks in advance.

Kind regards,

David van Leerdam