LambertZhaglog

> Doing some scheduler work and would like to consider the CPU and memory capacities of each node. I could use labels for this... @palade Did you mean we can...

**自研协议哪些特征**： 1. 自研协议没有frame的概念，即message 的header 和 body不被划分为多个frame传输 2. 每个message 都有 stream ID 3. 目前抓包来看，message 和 syscall的关系如下 1. 几乎全部，一个message 对应一个syscall 2. 存在一个message需要经过两次syscall 才接收完成的情况 3. 不存在多个message 被合并到一个syscall的情况 4. 自研协议和http/2 一样，是binary protocol，不是 ASCII protocol。[参见](https://hpbn.co/http2/#the-pros-and-cons-of-binary-protocols)...

#436 和 这个issue确实是说的同一个协议。#436 是一个测试场景，强制让协议工作在一问一答模式下的。这个协议是允许case1 场景存在的，case1 场景的存在是这个协议的一个优势。

好奇问一下，社区认为流式协议的特征是什么？为什么我所说的自研协议不是流式协议？

明白了，下周我找Magic协议的开发者仔细确认这个问题，“是否允许多个message出现在同一个系统调用中”。我现在能确定，Magic协议不存在单个message 被拆分为多个frame，也就不存在多个message的frame组合出现在一个系统调用中。

Magic协议允许每个message出现在同一个系统调用中，而且实际应用场景“这种组包”频繁发生

Rust，Python，C++

@hocktea214 case1: ConsumeEvent接收序列 request1, request2, response2, response1 之后，报文配对方法不是 > request2 报文会被merge到request1的尾部（即request2被隐藏），response1 会被丢弃，request1 和response2会被错误的配对在一起 我搞错了，应该是，request2 报文会被merge到request1的尾部，response1 报文会被merge到response2的尾部。所以 Kindling 解析DNS确实正确的处理了该场景。 想到一种新场景（记为case3），和case1类似，但Kindling解析DNS时是无法正确处理的。可能DNS不会遇到该场景，我现在也无法确信Magic是否存在该场景。该场景ConsumeEvent接收的序列是，request1, request2, response1, request3, response2, response3。 Kindling如果允许前一次调用distributeTraceMetric 时将未完成配对的request保留下来，供下一次调用distributeTraceMetric时response与其配对，可以解决这个问题 --- 您介绍的，针对case2的方案 > 解析出的request...

@dxsup 看起来如果换用uprobe，很大开发量，而且要求Kindling和Magic的实现版本绑定。 Magic协议没有Header编解码表。 我现在的考虑是，允许不拿全数据，丢弃因此受到影响的request/response message(不让他们生成DataGroup)。Kindling 最后输出的指标比真实值小一点，我想也是可以接收的。