Question

几乎所有文件传输软件，如[NetSupport，Radmin，PcAnyWhere ..]以及我在我的应用程序中使用的不同代码，当您发送大量小尺寸文件时，它会降低传输速度＆lt; 1kb ，如游戏文件夹，其中包含大量文件。

例如在局域网（以太网CAT5线缆）上我发送一个文件，比如一个视频，传输速率在2MB到9MB之间但是当我发送一个有很多文件的游戏文件夹时，传输速率约为300kb-800kb

因为我猜是因为发送文件的方式：

发送文件信息[file_path，file_Size]。

发送文件字节[循环到文件末尾]。

结束转移[确保完全收到]。

但是当您在网络上的共享文件夹上使用常规窗口 [copy-paste] 时，发送文件夹的传输速度总是很快，就像发送单个文件一样。
所以我试图使用[WCF服务c＃4.0]开发一个文件传输应用程序，它将使用LAN上可用的最大速度，我正在考虑这种方式：

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;
}

但我对使用多个Socket进行文件传输感到困惑，因为这将使用更多的端口和更多的时间（延迟收听和接受）。

这样做是个好主意吗？
需要解释一下是否有可能做，如何做，一个比tcp更好的协议。提前谢谢。

Answer 1

应该注意的是，你不会实现100％的局域网速度使用 - 我希望你不希望这样 - 那里有太多因素。

在回复你的评论时，你无法达到操作系统用来传输文件的水平，因为你比裸机更远离Windows。我相信Windows中的文件复制只比驱动程序本身高出一层或两层（甚至可能在文件系统驱动程序中） - 在WCF服务中你还要远一些！

您最简单的方法是将多个文件打包成档案并以这种方式传输，然后在接收端将整个包解压缩到目标文件夹中。当然，其中一些文件可能已经被压缩，因此不会受益 - 但总的来说，你应该看到一个很大的改进。对于可以保留目录结构的坚如磐石压缩，我考虑使用SharpZipLib

智能地使用压缩的系统（可能是中等级，低CPU使用率但在“可压缩”文件上运行良好）可能匹配或可能优于OS复制。 Windows不使用此方法，因为它对容错没有希望。在操作系统中，传输在文件中途停止仍然会保留任何成功的文件。如果转移本身被压缩和中断，一切都会丢失，必须重新开始。

除此之外，你可以考虑以下几点：

在尝试任何增强功能之前，默认情况下首先使用压缩工作。在某些情况下（取决于大小/没有文件），您可以简单地压缩整个文件夹，然后一次性传输。但是，超过一定的尺寸，这可能需要太长时间，因此您需要创建一系列较小的拉链。

将压缩文件写入磁盘上的临时位置，不要将整个内容缓冲到内存中。在将文件解压缩到目标文件夹后删除该文件。

考虑添加将某些文件类型标记为能够“裸”发送的功能，即未压缩。这样您就可以从压缩过程中排除.zips，avis等文件。也就是说，一个包含1百万个1kb zip文件的文件夹显然可以从打包到一个存档中受益 - 所以也许让自己设置一个最小尺寸，超过该尺寸，该文件仍将被打包到一个压缩文件夹（或者可能是一个文件）文件夹本身的磁盘比率的计数/大小 - 包括子文件夹。）

除了这个建议，你还需要四处寻找才能获得最佳效果。

Answer 2

或许，一个简单的解决方案是将所有文件收集到一个大流中（比如压缩它们，但只是附加以使其快速）并发送这一个流。这样可以提高速度，但会在两台设备上耗尽一些CPU，并且知道如何分离流中的所有文件。

但是，据我所知，使用更多端口只会是一个缺点，因为会有更多不同的流冲突，因此速度会下降。

LAN上具有最大速度的文件传输

2 个答案: