在LAN上以最大速度进行文件传输 [英] File Transfer with Maximum Speed on LAN
问题描述
几乎所有文件传输软件(例如[NetSupport，Radmin，PcAnyWhere ..])以及我在应用程序中使用的不同代码，都会在您发送大量小文件时降低传输速度. 1kb ，例如具有大量文件的游戏文件夹.
Almost all of file transfer softwares like [NetSupport, Radmin, PcAnyWhere..] and also the different codes i used in my application, it slows down the transfer speed when you send alot of small sized files < 1kb like Folder of a game that has alot of files.
例如在LAN(以太网CAT5电缆)上，我发送一个文件，比如说一个视频，传输速率在2MB到9MB之间.
但是当我发送包含大量文件的游戏的文件夹时，传输速率约为300kb-800kb
for example on a LAN (ethernet CAT5 cables) i send a single file, let say a video, the transfer rate is between 2MB and 9MB
but when i send a folder of a game that has alot of files the transfer rate is about 300kb-800kb
我猜这是因为发送文件的方式:
as i guess it's because the way of sending a file:
但是，当您在网络上的共享文件夹上使用常规窗口 [copy-paste] 时，发送文件夹的传输速率始终像发送单个文件一样快.
因此，我试图使用[WCF服务c#4.0]开发一个文件传输应用程序，该应用程序将使用LAN上可用的最大速度，而我正在考虑这种方式:
but when you use the regular windows [copy-paste] on a shared folder on the network, the transfer rate of sending a folder is always fast like sending a single file.
so im trying to develop a file transfer application using [WCF service c# 4.0] that would use the maximum speed available on LAN, and I'm thinking about this way:
Get all files from the folder.
if(FileSize<1 MB)
{
Create additional thread to send;
SendFile(FilePath);
}
else
{
Wait for the large file to be sent. // fileSize>1MB
}
void SendFile(string path) // a regular single file send.
{
SendFileInfo;
Open Socket and wait for server application to connect;
SendFileBytes;
Dispose;
}
但是我对于使用多个套接字进行文件传输感到困惑，因为这将占用更多的端口和更多的时间(监听和接受的延迟).
but im confused about using more than one Socket for a file transfer, because that will use more ports and more time (delay of listening and accepting).
那么做是一个好主意吗?
需要解释一下是否有可能做，如何做，这是一个比tcp更好的协议.
预先感谢.
so is it a good idea to do it?
need an explaination about if it's possible to do, how to do it, a better protocol than tcp that would meant for this.
thanks in advance.
推荐答案
应该注意，您永远不会实现100％的LAN速度使用-我希望您不希望这样做-有太多因素那里.
It should be noted you won't ever achieve 100% LAN speed usage - I'm hoping you're not hoping for that - there are too many factors there.
在回应您的评论时，您也无法达到操作系统用于传输文件的级别，因为与Windows相比，您与裸机的距离要远得多.我相信Windows中的文件复制仅在驱动程序本身(甚至可能在文件系统驱动程序中的内)上方一到两层-在WCF服务中，您的距离还很远！
In response to your comment as well, you can't reach the same level that the OS uses to transfer files, because you're a lot further away from the bare metal than windows is. I believe file copying in Windows is only a layer or two above the drivers themselves (possibly even within the filesystem driver) - in a WCF service you're a lot further away!
最简单的操作是将多个文件打包到归档文件中，然后以这种方式传输它们，然后在接收端将整个文件包解压缩到目标文件夹中.当然，其中一些文件可能已经被压缩，因此不会受益-但总的来说，您应该会看到很大的改进.对于可以保留目录结构的坚如磐石的压缩方式，我考虑使用 SharpZipLib
The simplest thing for you to do will be to package multiple files into archives and transmit them that way, then at the receiving end you unpack the complete package into the target folder. Sure, some of those files might already be compressed and so won't benefit - but in general you should see a big improvement. For rock-solid compression in which you can preserve directory structure, I'd consider using SharpZipLib
一个智能地使用压缩的系统(可能是中等级别的CPU使用率较低，但可以在可压缩"文件上很好地工作)可能匹配或可能优于操作系统复制. Windows不使用此方法，因为它对于容错没有希望.在操作系统中，文件中途停止传输将仍然保留所有成功文件.如果传输本身被压缩和中断，则所有内容都会丢失，必须重新启动.
A system that uses compression intelligently (probably medium-level, low CPU usage but which will work well on 'compressible' files) might match or possibly outperform OS copying. Windows doesn't use this method because it's hopeless for fault-tolerance. In the OS, a transfer halted half way through a file will still leave any successful files in place. If the transfer itself is compressed and interrupted, everything is lost and has to be started again.
除此之外，您还可以考虑以下内容:
Beyond that, you can consider the following:
在尝试任何增强功能之前，默认情况下首先使用压缩使其正常工作.在某些情况下(取决于大小/文件数)，您可以简单地压缩整个文件夹，然后一次性传输.但是，如果超出一定大小，这可能会花费太长时间，因此您将需要创建一系列较小的zip.
Get it working using compression by default first before trying any enhancements. In some cases (depending on size/no. files) it might be you can simply compress the whole folder and then transmit it in one go. Beyond a certain size, however, and this might take too long, so you'll want to create a series of smaller zips.
在接收压缩文件时将其写入磁盘上的临时位置，不要将整个文件缓冲在内存中.将文件解压缩到目标文件夹后，将其删除.
Write the compressed file to a temporary location on disk as it's being received, don't buffer the whole thing in memory. Delete the file once you've then unpacked it into the target folder.
考虑添加将某些文件类型标记为可以裸露"发送(即未压缩)的功能.这样，您可以从压缩过程中排除.zips，avis等文件.就是说，具有一百万个1kb zip文件的文件夹显然会从打包到一个存档中受益-因此，也许让您自己能够设置一个最小大小，超过该大小后，该文件仍会打包到压缩文件夹(或一个文件)中文件夹本身(包括子文件夹)的磁盘数量比率/大小.
Consider adding the ability to mark certain file types as being able to be sent 'naked'- i.e. uncompressed. That way you can exclude .zips, avis etc files from the compression process. That said, a folder with a million 1kb zip files will clearly benefit from being packed into one single archive - so perhaps give yourself the ability to set a min size beyond which that file will still be packed into a compressed folder (or perhaps a file count/size on disk ratio for a folder itself - including sub-folders).
除此建议外，您还需要四处摸索以获得最佳结果.
Beyond this advice you will need to play around to get the best results.
这篇关于在LAN上以最大速度进行文件传输的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
