What's the best way to use the 2.0 Framework to send multiple FTP commands during one connection?
The FtpWebRequest class seems to make a separate connection for each command.
I'd like to connect/login once, send two or more FTP commands, receive the response to each, then disconnect.
Karen
Thanks! I'm not worried about the client-side overhead of creating the FtpWebRequest object each time. But being able to avoid the login process for each command, and maintaining state on the FTP server (by continuing the same session) should be a big help.
BTW, when using this process, how do you finally end the connection? Will calling .Close on the FtpWebResponse object do it?
Or should I create an FtpWebRequest object, and specify "QUIT" as its .Method?
If so, could .Quit be added to the WebRequestMethods.Ftp enumeration? Karen
System.Net has a concept of connection management using Servicepoints. http://blogs.msdn.com/adarshk/articles/345411.aspx.. Connections are reused. If the idle time on connection elapses the default idle time (can be changed by a property in servicepoint manager) then the connection is cleaned up. the socket is basically closed.. So you need not bother about sending QUIT explicitly..
Malar wrote:
System.Net has a concept of connection management using Servicepoints. http://blogs.msdn.com/adarshk/articles/345411.aspx.. Connections are reused. If the idle time on connection elapses the default idle time (can be changed by a property in servicepoint manager) then the connection is cleaned up. the socket is basically closed.. So you need not bother about sending QUIT explicitly
That makes a lot of sense for HTTP connections. But for FTP, not having an explicit way to end the connection wastes resources on the FTP server. The server has to maintain the state of the session until an explicit QUIT, or the connection times out -- often a few minutes.
I guess that explains why there are no Ftp method values for changing the current directory on the FTP folder. With connection pooling, there's no way to be sure the FTP session you're accessing when you issue your second command is the same as the one you access with your first. And there's no guarantee some other program hasn't issued commands over the connection you're using, between commands of your own.
So commands that depend on the state of the FTP session could have some unexpected results.
I really do appreciate the added FTP support. But I wonder if grafting it onto the Http protocol support was the best design decision. Besides the wasted server resources, and server state issues, it probably accounts for the .GetDateTimestamp/LastModified and GetFileSize/ContentLength confusion too.
And the weird "FtpWeb" prefix too. :)
Karen
For that request where you want to close it you can set the keepalive to false
Did that work for you?
After the first command, issued with KeepAlive true, the response object's ExitMessage was blank. After the second command, when KeepAlive was false, the ExitMessage property became "221".
If I leave the KeepAlive property at its default value during both commands, the ExitMessage property is always blank.
Oddly, the BannerMessage and WelcomeMessage properties remained the same after both commands. I sort of thought they might be blank after the second command. But I guess the connection pool remembers these for persisted connections?
Karen
