apache
Is CRC validation for attachments under consideration?
Is your feature request related to a problem? Hi, I noticed that while brpc supports CRC checks, it currently doesn't validate the attachment field. In some cases, users put important payloads in attachments, so adding CRC for them could improve data integrity. I looked into the implementation and it seems not difficult to support. If this feature is considered useful, I’d be happy to work on a patch.
Thanks!
Describe the solution you'd like I suggest extending the existing CRC mechanism with two FLAGS:
-
brpc_checksum: enables CRC validation at the brpc layer. When enabled, only the message will be validated.
-
brpc_checksum_attachment: when enabled alongside brpc_checksum, CRC validation will also include the attachment field.
The checksum for the attachment can be computed by reusing the intermediate CRC state from the message part, so that the existing checksum_value field in the RPC meta can still be used without protocol changes.
Describe alternatives you've considered
Additional context/screenshots
For the CRC check of attachments, it is better to be implemented by the user. Considering that a request may pass through several servers, the protocol may change, but the data might remain unchanged. In this case, recalculating the CRC at each server would be a waste of resources. Therefore, no CRC is performed on attachments.
用户用的rpc可能是N个，每一个都实现，就等于是rpc实现了。如果影响性能，那元数据和都影响，如果选择只实现元数据，只是因为性能问题？更好的性能应该是元数据也可以让用户选择哪个接口用？这里是担心很多跳的问题？如果都用rpc实现的话，那每一跳都重新算，我觉得没问题。如果不想重新计算，可以放到controller里？
因为协议是用户不能感知的，baidu_std的协议自身有很多字段，所以协议部分，让框架做是合理的，保证协议部分所有内容都计算了。 而attachment，完全是给用户设置的，这也完全可以由用户计算。
因为协议是用户不能感知的，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.
你看压缩那部分的逻辑也是这么做的，我这边也是按照那个思路来实现checksum的，brpc的逻辑看上去是吧attachment完全交给用户没做任何处理。
因为协议是用户不能感知的，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.
有一些场景的 attachment 是从入口处开始就算好了，如果 rpc 框架再计算一遍不太合适。
还有一种情况是，有时候 crc 可能会藏在 attachment 内部的，这种一般是 attachment 内容和用户业务有关，本身就支持了自校验，所以也不需要 rpc 框架校验。
可能的做法是，用户来 set attachment crc，然后接收方只负责校验就行，如果用户没有 set attachment crc，rpc 框架可以根据配置来决定，是否在框架层计算 crc。
因为协议是用户不能感知的，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.
有一些场景的 attachment 是从入口处开始就算好了，如果 rpc 框架再计算一遍不太合适。
还有一种情况是，有时候 crc 可能会藏在 attachment 内部的，这种一般是 attachment 内容和用户业务有关，本身就支持了自校验，所以也不需要 rpc 框架校验。
可能的做法是，用户来 set attachment crc，然后接收方只负责校验就行，如果用户没有 set attachment crc，rpc 框架可以根据配置来决定，是否在框架层计算 crc。
赞同这个，可以是可选，attachment的rpc接口多了，挨个算不那么方便 set attachment crc，rpc 框架可以根据配置来决定，是否在框架层计算 crc。
你看压缩那部分的逻辑也是这么做的，我这边也是按照那个思路来实现checksum的，brpc的逻辑看上去是吧attachment完全交给用户没做任何处理。
看了一下压缩，看起来压缩有一部分原因是“gzip已经被protobuf支持了”？ 我甚至觉得，，，rpc把attachment给压了，也没问题？只要用户“知道”或者刻意为之～
你看压缩那部分的逻辑也是这么做的，我这边也是按照那个思路来实现checksum的，brpc的逻辑看上去是吧attachment完全交给用户没做任何处理。
看了一下压缩，看起来压缩有一部分原因是“gzip已经被protobuf支持了”？ 我甚至觉得，，，rpc把attachment给压了，也没问题？只要用户“知道”或者刻意为之～
我看讨论，感觉你们说的也没问题，就是attachment也给用户一个接口，用于决定是否在bRPC层面做crc校验。 @wwbmmm 你觉得可行吗？
