User (Old forums)MemberMarch 21, 2005 at 9:13 amPost count: 23064
I have a console application I am trying to write using .NET FTP v2.0 and it works perfect when the FTP SendFile function sends files that don’t take very long to transfer. However, when sending a 384MB file over a T1 it takes about 15 minutes or so and even through the file is completely transferred, the function never returns control back to the application.
THe same file works fine accross a faster connection. Besides the speed, the faster connection is using ACTIVE mode verses PASSIVE mode on the slower connection. But that shouldn’t make a difference. I have tried setting the timeout to a very high number, that doesn’t change how it works.
Anyone have a clue as to why this would happen? I almost wonder if it is something to do with how the FTP server is working, however, the standard FTP command in Windows works fine to transfer this file to the server.
Thanks in advance.
Applies to Xceed FTP for .NET. Imported from legacy forums. Posted by rjsimp (had 4239 views)User (Old forums)MemberAugust 20, 2005 at 9:55 pmPost count: 23064
This can happen when a timeout occurs somewhere in the connection path, whether it’s one of the firewalls at either EndPoint, or the server. As a result, troubleshooting WHERE the timeout occurs is rarely going to give you the satisfaction you would think, as you’ve rarely got full control over the device or service that is timing out.
My guess is that if you were to sniff the packets during your transfer, you would see that the server is sending you your “226 TRANSFER COMPLETE” message, but your client Control Channel has stopped listening.
The common solution is to implement some form of a KeepAlive in your client.
As far as I know, there are generally two types of KeepAlives available to you:
The FTP KeepAlive is where your client issues some form of Non-Operative FTP command, e.g. “NOOP”, “REST 0”, “PWD”, on some regular basis. In theory this keeps the Command Channel open by tickling the server’s session timeout, thereby allowing you to keep your connection to the server up and ready for whatever you may need. This type of KeepAlive is effective at informing firewalls that you want to maintain the connection, as well.
There are times when this type of KeepAlive is not as effective as you might think. I know of servers that monitor the Data Channel associated with any given Control Channel, and force the connection closed if there is no data transferred in a specific timeout.
There are additional issues with this method when you are maintaining multiple transfers per Control Channel.
The TCP KeepAlive is where your client enables the builtin TCP KeepAlive functionality which is part of the TCP/IP Protocol in most stacks. This is done via a call to the socket to set this value  via code, as the TCP KeepAlive is available to all applications using Sockets, but must be enabled on a per-application basis. You will also want to set the following registry key , as the normal KeepAlive time is set at 2 HOURS – much too short a time to make a difference for you.
As a side note, setting the registry value to that below is a recommended setting from Microsoft for tuning your TCP/IP stack.
Although Xceed has done a wonderful job of building their clients, they did NOT include the ability to set this value. If you want to enable this in your client code, you’ll need to purchase their BluePrint edition and extend it accordingly. Or, you could ask them to include it in the next release.
Hope this helped.
Socket.SetSocketOption(SocketOptionLevel.TCP, SocketOptionName.KeepAlive, 1)
Note, this call is commonly thought to SET the timeout value – this is incorrect. You are simply setting your socket to take advantage of the Global TCP KeepAlive value set by the registry.
Default: 7,200,000 (two hours)
New Value: 300,000 (5 minutes)
Note: This value is usually not set in the registry.
Applies to Xceed FTP for .NET. Imported from legacy forums. Posted by rbellamy (had 330 views)User (Old forums)MemberAugust 27, 2005 at 10:14 pmPost count: 23064
I realize it’s the height of rudeness to post a reply to one’s own post, but I thought I should mention some additional information I’ve come across since my last:
There may be nothing you can do to keep the command channel open. I’ve since seen IIS and SecureFTP close the channel, regardless of the TCP KeepAlive setting.
I think the most graceful (though still a hack) solution is to build your client-side code in such a way that you needn’t wait for the “226 Transfer Complete” response from the FTP server. I know WS_FTP in particular, does this – in every situation where I’m having timeouts on the command channel, or my client code hangs at the end of long transfers, WS_FTP can send or receive the file with apparent ease. I beleive this is because WS_FTP monitors the bytes tranferred, and when that equals the expected number of bytes to transfer, it calls the transfer complete – REGARDLESS of how the server responds. WS_FTP has other serious problems, but in this one area it seems to work better than other clients.
I realize this is a direct break from the FTP standard – but I’ve found that this is a real problem, and none of the solutions I’ve come up with, that adhere to the standard, seem to work. I’m very open to suggestions…
Applies to Xceed FTP for .NET. Imported from legacy forums. Posted by rbellamy (had 4109 views)
- You must be logged in to reply to this topic.