Thanks for the info.
DOS based FTP.EXE, however unmanaged still seems to do a good of getting data from one place to another and seems to use a minimal amount of ports which appear to be "the norm".
There are issues however that need to be addressed; for example, that the application is console based and does not lend itself well to automation beyond scripting and shelling to DOS.
So I suppose a solution would be to rewrite the core of FTP.EXE into a service easily managed by C#/JAVA (I seen some code that professes to to but have yet to see a viable implementation).
No, not a knock against your product. In fact, its beautiful.
I work for a BIG company that has restrictions in place regards ports.
How does one approach the company and say, to the effect, "for FTP to work smoothly you will most likely need to expend considerable effort on configuration or considerable cash on hardware that is FTP aware."
Because of the difficulties faced during implementation, I'll be forced to turn back the clock to FTP.EXE.
My company is big, REALLY big.
For you and for me, being an implementor, making this work is good.
The company is using MICROSOFT PROXY 2.0.
Does this PROXY service have the potential to be flexible, yet secure, in implementing your code?
And, I'm not sure what this means:
Many proxies support using the proxy address as the remote hostname, and remoteuser@remotehost as the username to login with.