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) 如何区分？
这两者如何共处呢？
这里且先提出问题，等后续再研究。