Build 1.0.3 - ACTIVE MODE problem

Question

Seems with a new release that perhaps a new thread be in order:)

We've had limited success on our end!

We hope to perform an Acceptance test shortly:)

Answer 1

Acceptance test was a success!

On to production!

Answer 2

Superb. This was a subtle bug that is great to get fixed.

Acceptance test was a success!

On to production!

Answer 3

Well... Almost...

Have noticed that sometimes, the code seems to choke during a transmission.

Code simply hangs until it's stopped.
Running the code again may resolve the issue.

The problem appears random but is none the less discouraging.

Answer 4

At what point in the code does it hang? Have you got a sample log file?

Well... Almost...

Have noticed that sometimes, the code seems to choke during a transmission.

Code simply hangs until it's stopped.
Running the code again may resolve the issue.

The problem appears random but is none the less discouraging.

Answer 5

It hangs here:

private NetworkStream GetDataStream() 
{
  Socket sock = data;

  // in active mode, we must accept the FTP server's connection
  if (connectMode == FTPConnectMode.ACTIVE) 
    {
      sock = data.Accept();
    }
    // ensure network stream owns the socket
  return new NetworkStream(sock, true);
}

----> sock = data.Accept();


Here's a log.
Assume the last entry is where the code hung:

230 User cuexxon logged in.
Login Successful for user 'cuexxon'
Forcing 'PASV' for all transports
Executing FTP job
Forcing transport to 'ACTIVE' mode (for FIREWALL access)
Server Environment: ''
---> PORT 192,168,133,145,6,113
200 PORT command successful
---> NLST
150 Opening ASCII mode data connection for file list
226 Transfer complete.
Downloading remote file 'msacddy.csv'
---> PORT 192,168,133,145,7,125
200 PORT command successful
---> RETR msacddy.csv
150 Opening ASCII mode data connection for msacddy.csv (4650 bytes)

Answer 6

Here's another.
As you can see, it got farther.
Assuming a port is blocked?

Downloading remote file 'BLMDUSCN09_03.CSV'
---> PORT 192,168,133,145,6,86
200 PORT command successful
---> RETR BLMDUSCN09_03.CSV
150 Opening ASCII mode data connection for BLMDUSCN09_03.CSV (22598 bytes)
226 Transfer complete.
Downloading remote file 'BLMDASAU09_04.CSV'
---> PORT 192,168,133,145,6,150
200 PORT command successful
---> RETR BLMDASAU09_04.CSV
150 Opening ASCII mode data connection for BLMDASAU09_04.CSV (4581 bytes)
226 Transfer complete.
Downloading remote file 'BLMDEUAF09_04.CSV'
---> PORT 192,168,133,145,6,182
200 PORT command successful
---> RETR BLMDEUAF09_04.CSV
150 Opening ASCII mode data connection for BLMDEUAF09_04.CSV (5846 bytes)
226 Transfer complete.
Downloading remote file 'BLMDCASA09_04.CSV'
---> PORT 192,168,133,145,6,207
200 PORT command successful
---> RETR BLMDCASA09_04.CSV
150 Opening ASCII mode data connection for BLMDCASA09_04.CSV (3100 bytes)

Answer 7

Hoping perhaps the problem @ the remote server or less desirable, @ the proxy/firewall, I ran standard FTP.EXE and guess what?

It failed also in the seeminly random way.

Not too sure where the fault is however but feel confident that my new software is working.

Sorry to scare you:)

Answer 8

On the client side, you may be running out of ports.

Each time you do a directory listing or a file transfer, a socket is created and destroyed.

However, when a socket is destroyed it goes into the TCP state called TIME_WAIT, which persists for a set period of time (often 2 minutes). This is to eliminate duplicate packets.

If many connections are made and closed, many sockets will be in TIME_WAIT. Eventually the limit will be breached and the application will hang until enough sockets go out of TIME_WAIT.

You can inspect socket states by using 'netstat -a'

The only cures are to slow down your transfers, or decrease TIME_WAIT, or allocate a higher number of file descriptors.

Here's another.
As you can see, it got farther.
Assuming a port is blocked?

Answer 9

"... cures are to slow down your transfers, or decrease TIME_WAIT, or allocate a higher number of file descriptors..."

How would I do that?

Answer 10

Slowing down transfers is a programming problem, e.g. sleep for a few seconds in between.

To change TIME_WAIT, see http://support.microsoft.com/default.as ... -us;120642

Not sure about file descriptors - in Unix it is called ulimit.

"... cures are to slow down your transfers, or decrease TIME_WAIT, or allocate a higher number of file descriptors..."

How would I do that?