FTP download speed issue: .NET socket programming vs using FtpWebRequest/Response objects

I'm trying to write a simple c# application which downloads a large number of small files from an FTP server.

I've tried two approaches:

1 - generic socket programming

2 - using FtpWebRequest and FtpWebResponse objects

The download speed (for the same file) when using the first approach varies from 1.5s to 7s, the 2nd gives more less the same results - about 2.5s each time.

Considering that about 1.4s out of those 2.5s takes the process of initiating the FtpWebRequest object (only 1.1s for receiving data) the difference is quite significant.

The question is how to achieve for the 1st approach the same good stable download speed as for the 2nd one?

For the 1st approach the problem seems to lay in the loop below (as it takes about 90% of the download time):

Int32 intResponseLength = dataSocket.Receive(buffer, intBufferSize, SocketFlags.None);    
while (intResponseLength != 0)  
{  
  localFile.Write(buffer, 0, intResponseLength);  
  intResponseLength = dataSocket.Receive(buffer, intBufferSize, SocketFlags.None);  
}

Equivalent part of code for the 2nd approach (always takes about 1.1s for particular file):

Int32 intResponseLength = ftpStream.Read(buffer, 0, intBufferSize);  
while (intResponseLength != 0)  
{  
  localFile.Write (buffer, 0, intResponseLength);  
  intResponseLength = ftpStream.Read(buffer, 0, intBufferSize);  
}  

I've tried buffers from 56b to 32kB - no significant difference.

Also creating a stream on the open data socket:

Stream str = new NetworkStream(da开发者_JAVA百科taSocket);  

and reading it (instead of using dataSocket.Receive)

str.Read(buffer, 0, intBufferSize);

doesn't help... in fact it's even slower.

Thanks in advance for any suggestion!

You need to use Socket.Poll or Socket.Select methods to check availability of data. What you do not only slows down operation, but also causes extensive CPU load. Poll or Select will yield processor time until data is available or timeout elapses. You can keep the same loop but include a call to one of the above methods, and play with timeouts (try values from 10 ms to 500 ms to find timeout, optimal for your task).