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

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.

Thanks - this was useful, but more importantly it lead me further, to a "handy" new change, introduced by Windows XP SP2:

Limited number of simultaneous incomplete outbound TCP connection attempts

The TCP/IP stack now limits the number of simultaneous incomplete outbound TCP connection attempts. After the limit has been reached, subsequent connection attempts are put in a queue and will be resolved at a fixed rate. Under normal operation, when applications are connecting to available hosts at valid IP addresses, no connection rate-limiting will occur. When it does occur, a new event, with ID 4226, appears in the system

Answer 2

Weird. In active mode, the FTP server is connecting to the client for transfer of data. In passive mode, the client is connecting to the server.

You'd think that passive mode (which has more outgoing connections) would choke, not active ...

I assume there is no conflict with XP SP2's built in firewall?

So, my DEV & TEST environments are both Windows XP SP2 (don't ask) and between this and the possible TIME_WAIT issue - I can see why my multithreaded ACTIVE client dies with no logs, error messages or anything - it simply halts.

I've been very careful, following the messages here, ensuring that each pooled thread has its own FTPClient instance, and its own "work data", protecting and locking my "workerCount" as necessary. Yet, it still dies in ACTIVE mode. Flip the setting to PASSIVE - and whooosh, no problems.

Answer 3

I assume there is no conflict with XP SP2's built in firewall?

Occasionally (on a new build), Windows XP "asks if I want to allow this program access" - and of course I grant it. But, in this particular corporate environment, while it is installed the policies do not allow us to modify/change it.

Ultimately, I'm not too worried (it works with passive), and the application will be running on a Server 2003 box, it should have less "environmental" issues to deal with. (Although true SMP may be a hastle, but I have been testing on my hyper-threaded machine and protected my critical data sections from lockups (fingers crossed)).

I just now convinced an admin to temporarily disable the firewall, and active connections hang - although, this time I get a "the socket was forcibly closed by remote host" error. Hmmm.

Answer 4

jkaczor,

Thanks for reviving my thread:)

Regards the corporate environment.... My copy of the code is running on our production box now without a hitch for perhaps 3 months so you'll probabably be OK.

Please recall that in the corp env, you have to jump hurdles to get code promoted to production so from an MIS standpoint, any code running there is certified to be there and generally enjoys priveliges to run freely.

Regards XP asking your permission... That sounds more like a 3rd party app intercepting the runtime. Here @ work, we have installed an application called STORMWATCH and it generally 'asks' my permission before code is run. Seems really that as far as the OS is concerned, DOTNET stuff is treaded like code being downloaded from the web - or so it appears.

Anyway, STORMWATCH is not installed on the prd server or if it is, it's a stripped version that does not restrict code from firing off.

BTW, we use Windows NT for our development machines and because of stromwatch (as mentioned), the PC asks permission before kicking off DOTNET code!

Answer 5

Then again, XP has a new handy malicious code blocker as per the latest round of patches so perhaps XP is the culpret!