场景：
- 客户端必须从服务器获取文件。他只需向服务器发送一个请求，就可以开始下载文件。这不是我们想要的。客户端有一个限制，即它不能接收大量数据(例如，文件大小为x字节，客户端最多可以接收y字节和x>>>y(。发送数据没有这样的限制。这意味着客户端可以随心所欲地向服务器发送数据。对服务器也没有限制。假设文件已经被压缩，并且无法减小文件大小
我会告诉你一个非常糟糕的解决方案：
- 客户端将向服务器询问文件的大小，然后将文件的所有可能组合发送到服务器。对于错误的组合，服务器将不会响应，而对于正确的组合，它将发送成功响应(如果服务器在错误组合的情况下以失败响应响应，那么我们将一无所获，因为响应的总大小将变为>=文件大小本身(。这将需要几个月的时间来传输几个mB的文件，但文件大小与服务器到客户端的数据传输率将是最好的
最有效的方法是什么？我们正在努力使上述比率最大化，同时保持合理的转移时间。
客户端发送文件名，服务器发送回文件内容的哈希(md5(。客户端尝试所有可能的组合以获得完全相同的md5。然后发送回猜测，服务器进行验证。
最有效的方法是什么？
除非您可以将数据压缩到y字节，否则根本不可能。
所有通过猜测来解决问题的尝试都是徒劳的，因为猜测的ACK/NACK答案也是通信的一部分。要区分两个x字节的数据，您需要x字节的答案。
从另一个角度来看：在你的猜谜游戏中，发送猜测的整个任务可以被一台自动机器取代，一个接一个地发送猜测。见鬼，服务器可以自己进行枚举。然后它会简单地说：嘿，#1051351的尝试是正确的。但要再次传输，您需要x字节。正如你所看到的，在另一个方向上的交流是完全无关的。
好吧，如果我理解正确的话，客户端接收的总字节数是有限制的，他需要从服务器获取一个文件(或者至少弄清楚该文件的内容(。
选项：
- 下载文件通常需要FILESIZE字节-如果FILESIZE>MAX_RECEIVE_bytes，则不可能
- 客户端从位置0开始，猜测字节，发送(猜测+位置(到服务器。服务器的响应是YES=正确，NOTHING=错误。使用这种方法，您还需要接收至少FILESIZE字节。并且您需要最多FILESIZE*FILESIZE次尝试
- 一次猜测更多字节(N(。这将为您提供接收的字节数=FILESIZE/N
所以我认为最好/最快的方法就是正常下载文件(如果这是限制的话，部分下载(。否则，您希望找到N的值，其中FILESIZE/N<最大接收字节。
编辑：我唯一能想到的另一件事是，客户端向服务器询问文件中0和1的数量，这样他就可以做出更有根据的猜测，从而减少可能组合的空间=请求数量=更快。