mjwtom

用户用的rpc可能是N个，每一个都实现，就等于是rpc实现了。如果影响性能，那元数据和都影响，如果选择只实现元数据，只是因为性能问题？更好的性能应该是元数据也可以让用户选择哪个接口用？这里是担心很多跳的问题？如果都用rpc实现的话，那每一跳都重新算，我觉得没问题。如果不想重新计算，可以放到controller里？

> 因为协议是用户不能感知的，baidu_std的协议自身有很多字段，所以协议部分，让框架做是合理的，保证协议部分所有内容都计算了。 而attachment，完全是给用户设置的，这也完全可以由用户计算。 我觉得，可以理解成，我把数据“交”给rpc传输，rpc可以有能力“保证”交给rpc和最终rpc收到的数据是一样的。参考tcp的checksum，也不是只算自己头的checksum，payload也会算。 The Checksum of the TCP is calculated by taking into account the TCP Header, TCP body, and Pseudo IP header.

> > > 因为协议是用户不能感知的，baidu_std的协议自身有很多字段，所以协议部分，让框架做是合理的，保证协议部分所有内容都计算了。 而attachment，完全是给用户设置的，这也完全可以由用户计算。 > > > > > > 我觉得，可以理解成，我把数据“交”给rpc传输，rpc可以有能力“保证”交给rpc和最终rpc收到的数据是一样的。参考tcp的checksum，也不是只算自己头的checksum，payload也会算。 The Checksum of the TCP is calculated by taking into account the TCP Header, TCP body, and Pseudo...

> 你看压缩那部分的逻辑也是这么做的，我这边也是按照那个思路来实现checksum的，brpc的逻辑看上去是吧attachment完全交给用户没做任何处理。 看了一下压缩，看起来压缩有一部分原因是“gzip已经被protobuf支持了”？ 我甚至觉得，，，rpc把attachment给压了，也没问题？只要用户“知道”或者刻意为之～