0

几乎所有的文件传输软件，如 [NetSupport, Radmin, PcAnyWhere..] 以及我在我的应用程序中使用的不同代码，当您发送大量小于 1kb的小文件时，它会减慢传输速度，例如游戏文件夹很多文件。

例如在 LAN（以太网 CAT5 电缆）上，我发送一个文件，比如说一个视频，传输速率在 2MB 到 9MB 之间，
但是当我发送一个包含大量文件的游戏文件夹时，传输速率约为 300kb- 800kb

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

  • 发送文件信息 [file_path,file_Size]。
  • 发送文件字节[循环到文件末尾]。
  • 结束传输 [确保已完全接收]。

    但是当您在网络上的共享文件夹上使用常规窗口[复制粘贴]时，发送文件夹的传输速度总是像发送单个文件一样快。
    所以我尝试使用 [WCF service 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;
}

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

    那么这样做是个好主意吗？
    需要解释是否可以做，如何做，比 tcp 更好的协议，这意味着。
    提前致谢。

    • 4

    2 回答 2

    3

    应该注意的是，您永远不会达到 100% 的 LAN 速度使用率——我希望你不希望这样——那里有太多因素。

    作为对您的评论的回应，您无法达到操作系统用于传输文件的相同级别，因为您距离裸机比 Windows 更远。我相信 Windows 中的文件复制仅比驱动程序本身高一两层（甚至可能在文件系统驱动程序中）——在 WCF 服务中，你离得更远了！

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

    智能使用压缩的系统（可能是中等级别、低 CPU 使用率，但可以很好地处理“可压缩”文件）可能会匹配或可能优于操作系统复制。Windows 不使用这种方法，因为它对容错毫无希望。在操作系统中，文件传输中途停止的传输仍会保留任何成功的文件。如果传输本身被压缩和中断，一切都会丢失，必须重新开始。

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

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

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

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

    除了这个建议之外，您还需要尝试获得最佳结果。

    于 2012-04-16T13:21:40.933 回答
    0

    也许，一个简单的解决方案是将所有文件收集到一个大流中（比如压缩它们，但只需附加以使其快速）并发送这个流。这将提供更快的速度，但会占用两个设备上的一些 cpu 以及如何分离流中的所有文件的好主意。

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

    于 2012-04-16T12:57:26.790 回答