Yang,Liming

这个问题最终解决了吗？遇到问题修改connection_group不是最终方案吧。

@wwbmmm 感觉这个问题还挺关键的，需要安排一个比较了解这部分代码的同学跟一下。我们这边也遇到过这个问题。

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...

因为协议是用户不能感知的，baidu_std的协议自身有很多字段，所以协议部分，让框架做是合理的，保证协议部分所有内容都计算了。 而attachment，完全是给用户设置的，这也完全可以由用户计算。

你看压缩那部分的逻辑也是这么做的，我这边也是按照那个思路来实现checksum的，brpc的逻辑看上去是吧attachment完全交给用户没做任何处理。

> > 你看压缩那部分的逻辑也是这么做的，我这边也是按照那个思路来实现checksum的，brpc的逻辑看上去是吧attachment完全交给用户没做任何处理。 > > 看了一下压缩，看起来压缩有一部分原因是“gzip已经被protobuf支持了”？ 我甚至觉得，，，rpc把attachment给压了，也没问题？只要用户“知道”或者刻意为之～ 我看讨论，感觉你们说的也没问题，就是attachment也给用户一个接口，用于决定是否在bRPC层面做crc校验。 @wwbmmm 你觉得可行吗？

新版本的代码有修改，不过span的使用也是需要注意一下的。你的使用场景是怎么样的？会启动bthread，并发操作span吗?

> > 新版本的代码有修改，不过span的使用也是需要注意一下的。你的使用场景是怎么样的？会启动bthread，并发操作span吗? > > 服务调用时会并发请求，比如我们出现core的服务是a，服务a内部调用a->b，a->c，a->d，三次请求是并发的，未显示使用bthread，用的是brpc异步请求。 这种使用方式会有问题吗？ 按说异步RPC也没问题，只是b、c、d必须保证在a之前结束。

mysql的prepared statement协议的支持。 遇到的两个问题解决方案如下： 1、prepared statement首先是在某个连接上创建一个statement id，后续操作可以根据这个statement id向这个连接发送后续的请求。同一个语句在每个连接上的statement id是不同的。在pooled模式下，每次RPC选择的连接是不同的，所以需要记录SocketId和statement id的关系，我们这里称为id_map。但是一个SocketId有可能关闭，然后又重新建立起来，这个新SocketId对应的连接没有这个statement id。id_map没有机制可以做到同步更新，保存的SocketId与statement id关系信息是旧的关系。这样就会产生问题。 这个问题的修改方式是，给socketid对应的fd一个唯一的版本号，每次通过stmt_id找到socketid的时候对比一下版本号，版本号一致说明fd没有变化，版本号不一致说明fd变化过。 2、目前还不能支持single模式，唯一的原因就是auth部分，正常auth多个请求会竞争发送auth，后续操作就不需要发送auth了，auth不用等待服务端应答，就可以让其他请求继续发送。但是mysql的auth和这个逻辑不通，mysql的auth首先接收mysql-server发送过来的salt，客户端根据salt加密密码，再把加密后的密码发送给服务端。这样的逻辑如果不等待服务端应答就解锁别的请求，就会出现发送auth的请求落后于正常的请求，导致消息乱序。 这个目前就先不支持single模式了。

> 求教, mysql协议现在是什么状态了呢 目前没时间开发这个，有兴趣可以贡献一下。