在layotto的invoker channel是否可以直接将xframe在mosn downstream.go的OnReceive函数开始调用

[carolove]

现行的layotto 调用mosn的机制是通过一个net.pipe将layotto的数据塞入mosn的layer 4网络层，
这样带来的好处是高度的和mosn集成，但是同样带来一些问题，最主要的问题是，需要带来额外的损耗，包括编解码以及网络
我觉得应该可以这么设计
1、在layotto的invoker channel开发一个direct channel
2、这个direct channel初始化的时候，不再建立mosn的layer 4 connection，而是直接初始化一个对应的proxy以及一个downstream stream
3、在Do invoker的时候，将layotto的数据req构建成xframe以后通过onReceiveStream.OnReceive(OnReceiveCtx, xreq.eq.GetHeader(), xreq.GetData(), nil)的方式写入
4、在wait for response channel中，通过第二步构建proxy用到的fake connection的Write函数拿到对应的callback response，如果可以更进一步，甚至可以在upstream endStream 的时候如果downstream并不是一个connection对象可以直接把xframe写过去，而不是encode后写入iobuffer

[wenxuwan]

layotto和mosn之间的通信的话这边用的是net.pipe，是不经过传输层，直接内存级别的数据拷贝，损耗还是很小的。但就像你说的为什么塞到的是mosn的L4 OnAccept， 是因为mosn在L4对流量进行了很多的处理，很难把这个逻辑再移动到layotto里面，所以就直接通过pipe让mosn感知不到下游，layotto把数据包拼好后通过pipe(非L4)交给mosn处理。

[zhenjunMa]

@carolove 我看到了 @alpha-baby 的性能测试报告，正如 @wenxuwan 说的，当时考虑到如果使用onReceiveStream.OnReceive这种方式，可能会丢失一些在OnAccept 中设置的上下文信息导致后续处理不可预测的问题，后面我们会定位的一下影响性能的原因，如果这里影响较大，那还是会考虑使用你说的方案来优化

[alpha-baby]

@carolove 我看到了 @alpha-baby 的性能测试报告，正如 @wenxuwan 说的，当时考虑到如果使用onReceiveStream.OnReceive这种方式，可能会丢失一些在OnAccept 中设置的上下文信息导致后续处理不可预测的问题，后面我们会定位的一下影响性能的原因，如果这里影响较大，那还是会考虑使用你说的方案来优化

如果方便，可以给个对比报告出来

[carolove]

那等着你们的优化报告，这个issue先关闭了