算法难题 - 棘手的服务器到客户端文件传输

Question

情景：

• 客户端必须从服务器获取文件。他只需向服务器发送请求并开始下载文件即可。这不是我们想要的。客户端有一个限制，它无法接收大量数据（例如，x字节的文件大小和客户端可以接收最多y字节和x＆gt;＆gt;＆gt;＆gt; y）。发送数据没有这样的限制。这意味着客户端可以根据需要向服务器发送尽可能多的数据。对服务器也没有限制。假设文件已经压缩，文件大小无法减少。

我会说一个非常糟糕的解决方案：

• 客户端将询问服务器的文件大小，然后将该文件的所有可能组合发送到服务器。对于错误的组合，服务器将不响应，并且对于正确的组合，它将发送成功响应（如果服务器在错误组合的情况下响应失败响应，那么我们赢得任何东西，因为响应的总大小将变为＆gt; =文件大小本身）。传输几个mB文件需要几个月的时间，但文件大小到服务器到客户端的数据传输率最好。

最有效的方法是什么？我们正在努力使上述比率最大化，同时保持合理的转移时间。

Answer 1

客户端发送文件名，服务器发回该文件内容的哈希值（md5）。客户端尝试所有可能的组合以获得完全相同的md5。然后发送回猜测，服务器验证。

Answer 2

  

最有效的方式是什么？

除非您可以将数据压缩到 y 字节，否则

。

所有通过猜测来解决问题的尝试都是徒劳的，因为猜测的ACK / NACK答案也是通信的一部分。要区分x个字节的两个数据，需要x个字节的答案。

从不同角度看一下：在猜测游戏中，发送猜测的整个任务可以由自动机器替换，一个接一个地猜测。哎呀，服务器可以自己进行枚举。然后它会简单地说：嘿，＃1051351尝试是正确的。但要再次传输，您需要 x 字节。如您所见，另一方面的沟通完全无关紧要。

Answer 3

好的，如果我理解正确，客户端收到的总字节数有限制，他需要从服务器获取文件（或者至少弄清楚该文件的内容）。

选项：

• 下载文件通常需要FILESIZE字节 - 如果FILESIZE＆gt;则不可能。 MAX_RECEIVE_BYTES
• 客户端从位置0开始，猜测字节，发送（猜测+位置）到服务器。服务器响应YES =正确，NOTHING =错误。使用这种方法，您还需要至少接收FILESIZE字节。并且你需要最大的FILESIZE * FILESIZE尝试。
• 一次猜出更多字节（N）。这将为您提供一些接收的字节= FILESIZE / N。

所以我认为最好/最快的方法就是正常下载文件（部分内容，如果这是限制）。 否则，你想要找到N的值，其中FILESIZE / N＆lt; MAX_RECEIVE_BYTES。

修改： 我能想到的另一件事是，客户端向服务器询问文件中的0和1的数量，这样他就可以进行更多有根据的猜测，从而减少可能组合的空间=请求数量=更快。