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

Question

设想情况：

• 客户端必须从服务器获取文件。他只需发送一个请求到服务器并开始文件下载。这不是我们想要的。客户机有一个限制，它不能接收大量数据(例如，文件大小为x字节，客户机可以接收最大y字节和x >>>> y)。在发送数据方面没有这种限制。这意味着客户端可以向服务器发送任意数量的数据。对服务器也没有限制。假设文件已经压缩，文件大小无法缩小。

我要告诉你一个非常糟糕的解决方案：

• 客户端将从服务器询问文件的大小，然后将所有可能的文件组合发送到服务器。对于错误的组合，服务器将不会响应，而对于正确的组合，它将发送成功的响应(如果服务器在出现错误组合时以失败响应响应，那么我们将不会获得任何结果，因为响应的总大小将变成文件大小本身的>= )。这将需要几个月的时间来传输一些mB文件，但是文件大小到服务器到客户端的数据传输比率将是最好的。

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

Answer 1

客户端发送文件名，服务器发送文件内容的散列(md5)。客户端尝试所有可能的组合以获得完全相同的md5。然后发回猜测，服务器验证。

Answer 2

最有效的方法是什么？

除非您可以将数据压缩为y字节，否则根本不可能是。

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

从不同的角度看一看:在您的猜测游戏中，发送猜测的整个任务可以由一个自动机器代替，一个接一个地发送猜测。见鬼，服务器可以自己做枚举。然后它会简单地说:嘿，#1051351的尝试是正确的。但是要传输，再次，你需要x字节。正如你所看到的，在另一个方向上的交流是完全不相关的。

Answer 3

好的，如果我正确地理解了您的意思，那么客户端接收的总字节是有限制的，他需要从服务器获得一个文件(或者至少计算出该文件的内容)。

选项：

• 下载文件通常需要文件大小字节-如果文件大小> MAX_RECEIVE_BYTES，则不可能
• 客户端从位置0开始，猜测字节，将(猜测+位置)发送到服务器。服务器的响应要么是“是”=“正确”，要么是“没有”。使用这种方法，您还需要至少接收文件大小的字节。你需要最大的文件大小*文件大小的尝试。
• 一次猜更多的字节(N)。这将给出接收到的字节数=文件大小/N。

因此，我认为最好/最快的方法就是正常下载文件(如果这是限制的话，可以分几部分下载)。否则，您希望为N找到一个值，其中文件大小/N< MAX_RECEIVE_BYTES。

编辑：我唯一能想到的另一件事是，客户机询问服务器文件中0和1的数量，这样他就可以做出更有根据的猜测，从而减少可能组合的空间=请求数=更快。