https://mp.weixin.qq.com/s/MHW_aBSL72YNee9bVWWeaw
简单介绍HintHandler的实现。 
1. 基本功能 实现Hint请求的处理逻辑。 类参数：passthrough：是否把Hint请求透传给下游节点处理； 2. diplomacy node HintHandler是一个适配器节点：
1) clientFn 把HintHandler看到的上游节点的参数，转换为下游节点看到的HintHandler节点的参数。 这里把原sourceId左移一位，最低位用于编码信息。 2) managerFn 把HintHandler看到的下游节点的参数，转换为上游节点看到的HintHandler节点的参数。 这里根据情况，为下游节点新增支持Hint操作的能力：a. 如果下游节点支持Hint操作，并且允许透传Hint请求（passthrough），那么直接使用下游节点的能力；否则：b. 如果下游节点支持PutPartial，则使用PutPartial的能力；否则：c. 如果下游节点的区域类型为GET_EFFECTS，则使用Get的能力；否则：d. 告诉上游节点，不支持Hint操作； 3. lazy module lazy module用于实现HintHandler的内部逻辑。 1) 成对的输入边和输出边 
2) 默认in直连out 
3) 确保HintHandler支持Hint请求 
注意这里使用的是edgeIn，而不是edgeOut。edgeIn.manager是指HintHandler节点作为的manager。 这里判断的意思就是确保HintHandler支持Hint请求。无论是透传，还是由HintHandler代为处理。 4) usePP & useGet 
usePP：使用PutPartial消息为下游manager处理Hint请求；useGet：使用Get消息为下游manager处理Hint请求； 5) mapPP & mapGet 判断当前请求的地址对应的manager使用PP还是Get处理Hint请求：
6) 转换请求到out.a 
7) 转换响应到in.d A. 如果使用Get处理Hint，则需要丢弃响应消息AccessAckData： 
a. 如果Get的能力小于或等于beatBytes，就不存在burst请求，都是单beat请求。这个单beat请求会直接被转换（transform），所以不需要丢弃；b. 如果Get的能力大于beatBytes，就需要把除去最后一个的beat丢弃；
B. transform是编码位，代表着是否需要把Get和PP的响应转换为HintAck：
8) 处理Acquire操作的source： 因为不需要HintHandler做处理，所以直接把source移位即可：
9) repeater 用于处理burst PutPartial转换：
A. 因为Hint请求不包含数据，所以其size可以很大。PutPartial包含数据，所以当size大于beatBytes时需要分成多个beat组成burst请求。 即一个size大于beatBytes的Hint请求，被转换成了包含多个beat的PutPartial请求。a. The Control type signals (i.e., *_address, *_size,*_param) must be held constant for the entire burst. 
b. mask为0，不真的写入数据：
B. 直到所有的PutPartial beats发送完成，才允许in.a继续输入：
repeater.io.repeat在最后一个beat之前的beat时都为真。意味着即便从repeater.io.deq取走数据，repeater.io.full也为真：
此时repeater.io.enq.ready为假：
所以这里repeater的用法与Fragmenter中类似，都是用来Hold住in.a而等待out.a的。 4. 默认连接与特定连接 1) 默认连接 默认out与in直连：
即in.a/b/c/d/e与out.a/b/c/d/e分别相连，这属于bulk connect。 2) 连接特定域 这里又把新的输出连接到out.a的部分域上：
3) 如何区分？ 这两者如何共处呢？这里且先提出问题，等后续再研究。
