Li Peng Fei
Li Peng Fei
https://github.com/Liv1020/yii2-redis This is ext for predis, predis can create phpredis connection class to use phpredis. It's compatible with yii2-redis
我觉得3.0的通信协议会是一个Hprose protocol，基于这个协议会有多个现实方式，比如刚才 @MiyamuraMiyako 提到的KCP或者tcp、mq等。Hprose protocol应该抽象比较高级的功能，比如双向流、限流等。
> 在服务器返回数据时，如果上下文对象中的 Header 信息有被添加或修改，则返回结果时，首先返回 H 标记，再返回 R 标记，否则直接返回 R 标记。 > 客户端收到返回的 Header 信息后，对上下文中的 Header 数据做出相应的修改，用户可以在输入过滤器，中间件中对其进行访问。调用返回时，默认不会改动客户端的全局 Header 设置，但是用户可以在输入过滤器，中间件中根据上下文中已经改动的 Header 来自行对全局 Header 设置做出改动。 服务端可以修改并且返回H这个感觉不是很必要，这个好像也不是上下文应该有的。实现方式觉得方法2会好一点
抽离出来H不依赖http、tcp是对的，我也理解你说的。按照你说的应该是Request H和Response H，而上下文应该使用Request H 来传递，这样层次更清晰。因为Response H并不是上下文该有的东西
是的，请求包里面包含：Request H、R 响应包里面包含：Response H、R Context通过Request H 传输，token可以被Response H传输。类似我们定义一个协议，Context、token等只是通过协议传输的信息，这样在定义上更加明确一些。
我前面说的Request H并不是特指Http Request Header。我的想法是Hprose自己定义一个传输协议，这个协议不依赖于http、tcp、mq等，这个协议客户端调用包含：Request share data、R，服务端返回包含：Response share data、R。这个是协议部分的定义。 Context是客户端调用的时候告诉服务端上下文的，他是在Request share data里面传输。 > 最后当服务器返回结果时，如果 context.Header 没有做过修改，则不返回 H 标记，否则，只将有差异的部分作为 H 标记返回。 这个严格来看并不应该在Context里面定义（定义上不会出现被调用方修改上下文的情况），他可能叫其他的。或许我有些对定义偏执，但是我觉得明确之后利于理解
当你说反向调用我才知道你为什么Response share data 需要Context，但是我觉得这样设计反向调用不对。 
> 反向调用并不是如上图那样实现的，反向调用是客户端提供服务，服务器端通过 Context.Clients.Invoke 来对客户端发布的方法进行调用。 这个设计会让调用方即使Client还是Server，这种做法太过针对、别扭。上面的图只是针对反调用给出的更加简单清晰的解决方式，可以使用中间件解决。Core最好灵活简单
各位，docker时区设置了吗？