《分布式系统概念与设计》--使用TCP流实现请求应答协议

在4.3.2节中提到，确定合适的接收数据报缓冲区大小是很难的，在请求应答协议，服务器使用缓冲区接收请求消息，客户端用缓冲区来接收应答消息。因为过程的参数或者结果可能是任意长度的，所以数据报长度的限定（通常是8KB）在透明的RMI和RPC系统中是不适合的。

实现基于TCP流的请求应答协议的原因之一是希望避免实现多包协议，因为TCP流可以实现任意长度的参数和结果。尤其是，java对象序列化是一种允许在客户服务器之间发送参数和结果的流协议，该协议使可靠地传输任意长度的 对象集合成为可能。如果使用TCP协议，就能保证可靠的传输请求和应答消息，因此对于请求和应答协议来说就没有必要去处理消息的重传，重复消息的过滤，历史使用的问题。另外，流控制机制可以传递大量的参数和结果，不需要采用特殊措施来避免大规模的接收。因此，tcp协议被用于请求应答协议，因为它简化了他们的实现。如果在客户服务之间连续在同一个流上发送相同的请求-应答消息，那么不需要在每次远程调用上都有连续的开销。当发送请求消息后不久收到应答消息时，TCP确认消息引起的开销也会减少。

然而，如果应用不要求TCP提供的所有机制，那么更有效的方法是，定制一个基于UDP实现的协议。例如，因为SUN NFS在客户服务器之间传输固定长度的文件块，所以它不要求提供对发送无限长消息的支持。此外，把它的操作设计成幂等操作，这样为了重传丢失的应答消息而多次执行操作也没有关系，同时也没有必要去维护历史。