W wp00000008 Unregistered / Unconfirmed GUEST, unregistred user! 2005-03-19 #21 tcp是流式的，发送数据只能保证次序，不能保证发送的次数和接收的次数相同。 即发送100个字节，可能一次接收完毕，也可能10次才能接收完毕。 你的是4k，早已超过MTU，不可能一次收到。
A appfirst Unregistered / Unconfirmed GUEST, unregistred user! 2005-03-19 #22 MTU?MTU应该是对IP层适用的概念，而且不同主机的MTU可能不一样，即使你的数据包满足当前主机的MTU要求，但不能保证在传递过程中其他主机不会对其进行分段操作，最终可能还是会多次接收。至于记录边界的问题，虽然TCP不保留，但我们自己还是需要处理的。
MTU?MTU应该是对IP层适用的概念，而且不同主机的MTU可能不一样，即使你的数据包满足当前主机的MTU要求，但不能保证在传递过程中其他主机不会对其进行分段操作，最终可能还是会多次接收。至于记录边界的问题，虽然TCP不保留，但我们自己还是需要处理的。
A appfirst Unregistered / Unconfirmed GUEST, unregistred user! 2005-03-19 #23 其实，我个人认为怎样接收并不是问题，问题是出现问题了，你应该怎样解决！至于我之前提出的问题我已经圆满解决，正在用：），我保留此贴的目的是希望大家多交流一下这方面的经验和问题！
A appfirst Unregistered / Unconfirmed GUEST, unregistred user! 2005-03-19 #24 比如对一个实时发送数据同时客户端对数据的完整性要求较高的程序里，作为服务端，当一个客户端阻塞的时候，是断开它，还是在下一轮补发，还是继续等待...需要根据业务要求情况来判断，但对一个复杂应用，可能无法前期确定处理方法，必须在实时处理过程解决，那这就成了一个问题，因为答案不可能是最优的，好像很难使一个解决方案对所有情况都是最优的。就象我使用7,8种方法来获取对两幅图像的比较结果，发现没有一种能够准确的检查出所有测试图像的全部差异。 我想，如果答案不可能确定，那么重点就应该在如何获取更多的答案。
比如对一个实时发送数据同时客户端对数据的完整性要求较高的程序里，作为服务端，当一个客户端阻塞的时候，是断开它，还是在下一轮补发，还是继续等待...需要根据业务要求情况来判断，但对一个复杂应用，可能无法前期确定处理方法，必须在实时处理过程解决，那这就成了一个问题，因为答案不可能是最优的，好像很难使一个解决方案对所有情况都是最优的。就象我使用7,8种方法来获取对两幅图像的比较结果，发现没有一种能够准确的检查出所有测试图像的全部差异。 我想，如果答案不可能确定，那么重点就应该在如何获取更多的答案。
