5

我正在构建一个 .NET 远程客户端/服务器，它将传输数千个不同大小的文件（从几个字节到数百 MB 不等），我想要一些关于实现此目标的最佳方法的反馈。在我看来，有几个选择：

  • 将整个文件序列化到我的远程处理对象中并一次传输，无论大小。这可能是最快的，但是传输过程中的失败需要重新传输整个文件，无法恢复。
  • 如果文件大小大于小文件（如 4KB），请将其分成 4KB 的块并远程处理，在服务器上重新组装。除了复杂性之外，由于持续的往返和确认，它更慢，尽管任何一个部分的失败都不会浪费太多时间。
  • 在我的应用程序中包含 FTP 或 SFTP 服务器之类的东西 - 客户端将通知服务器它开始使用远程处理，上传文件，然后使用远程处理来通知完成。我想在我的应用程序中包含所有内容，而不是需要单独的 FTP 服务，但如果需要，我愿意接受这个选项。
  • 使用某种声明的 TCP 连接或 WPF 或其他为处理故障或能够执行某种检查点/恢复而构建的传输方法。
  • 还有其他我想念的吗？

最灵活/可靠的传输方式是什么？我不太关心速度，但更关心可靠性 - 我希望文件移动，即使它很慢。由于客户端和服务器将是多线程的，如果连接允许，我可以同时传输多个文件。

感谢您的反馈 - 我将提供赏金以获得有关人们实现此目标的方法的一些建议。

4

3 回答 3

4

BITS（后台智能传输服务）是一个很好的解决方案。它拥有多年的内置经验

一些起点是

于 2010-03-31T21:55:04.540 回答
1

尽管冷静确实回答了您从 OSI 第 4 层生活中提出的问题，但我觉得您更多地关注问题中的应用程序层。TCP 确实可以处理生活网络方面的所有问题，从延迟、传输窗口等。但是，它并不能直接确定如果用户过早结束下载会话然后决定稍后从中断的地方继续下载会发生什么。

要从不同的角度回答您的问题，我绝对建议将文件分块并为所有连接编制索引，无论速度如何。一旦下载了整个文件，它们就可以在客户端上再次重新组装。这允许用户暂停下载会话并继续。

至于确定速度，可能有预先构建的方法来执行此操作，但您可以使用的一种方法是构建自己的速度测试：向客户端发送 1 MB（上传）并让它在收到后发送响应。1100 除以从客户端获取响应所需的时间，就是客户端从服务器下载所需的 KB/s。反之亦然，以测试从客户端上传。

至于传输，我建议使用现有技术。 SFTP支持经过身份验证的加密数据传输。它基本上是 FTP，但通过 SSH。在某处应该有可用的 API 来与之交互。

顺便说一句，我从来没有做过你所说的任何事情，但希望我的想法至少给你几个选择来考虑。

于 2010-03-30T22:21:40.020 回答
0

这就是 TCP 本身的目的，并在数十年或艰苦的测试中进行了调整。远程处理用于小型 RPC 调用，而不是大型文件传输。您应该简单地使用 TCP 套接字来传输数据，让低层协议担心延迟、传输窗口、MTU 等。

于 2010-03-29T16:19:52.933 回答