在上一节中我们讲到了GetBlocks接口，在收到Keys请求之后，会通知各个模块缓存关于KEYS的请求，并且开始通过路由层来寻找对应的数据。在将KEYS存入WantManager的同时，WantManager会把已经建立链接的节点信息存储在一个Map中，当收到GetBlocks请求之后，Want Manager会马上将这些请求发送给这些节点，下图是节点信息的Map数据结构。
可以看到每一个节点的PeerID对应一个Message Queue，Message Queue由2个部分组成，一个是Want List 一个是Out Queue。Out Queue里面又有一个Want List 和一个Block List，Want List存储的是key对应的请求，Block List存储的是Key对应的数据。
每一个消息队列都有自己的run loop，当有新的查找指令到来时，run loop负责将查找指令通过msgSender对象发出，因为我们使用的是Peers 这个Map，因此我们知道命令接收者的peer id，将该id传给Message sender对象之后，它就可以通过网络层建立链接并将查找指令传递给消息接受者。
以上是对已经与本节点建立链接的节点，接收本节点的查找命令的逻辑，我们在前一节重点讲解了接收到查询命令之后，各个缓存存储查找指令的方式，以及各个缓存自己的run loop是如何逐步的执行数据查询命令的。接下来我们讲解作为被查询节点，当接收到这些查询命令之后是如何响应的。
首先我们假设其实状态下，Want Manager并不管理任何其它节点信息，我们在前面的章节中说过，GetBlocks有一个选择是将被查询对象的KEY的数组的第一个KEY作为对象调用findkeys（），上图是前面流程的概要图，并增加了其它节点收到这个链接请求后的动作，首先其他节点与本节点建立数据链接，成功建立链接之后，IPFS的协议层会将其它节点的信息加入到Want Manager的其它节点列表中进行管理。上图就是每一层协议的关键处理函数。
当获得其他节点信息之后，我们知道有一个RUN LOOP会发起Send Message请求，本节点会将需要查找数据的KEY值发送给所有可用的其他节点上，这些请求被发送的其它节点。其它节点收到这个数据查询请求之后，通过网络层接受数据，并将数据组合为数据交换层能够理解的BitSwapMessage数据格式。然后将数据放到Engine这个模块的一个队列中，这个队列叫做PeerRequestQueue。
上图就是PeerRequestEngine的数据结构，他保留一个列表，用来出出具体的数据，一个TaskMap用来管理请求任务，每一个接受的数据都会被封装成为一个任务。还有两个Map分布用来存储发送请求过来的对端的信息，一个是正常的partners的Map，另一个是被冻结的Partner的Map，在IPFS的数据交换协议里面，Engine会管理本节点与其它节点的数据交换的数量，以防止恶意攻击，如果一个节点只获取数据，并不提供数据，那么这个节点可能会被其它节点加入到冻结列表中。
这个数据请求队列也有一个Run Loop，不停地检查是否有工作，按照顺序将处在队列头的请求Pop出来，得到一个请求的任务task，然后节点通过查找本地的数据存储，将task中存储的数据请求key取出，在寻找key对应的具体数据block，得到这个数据之后，调用WantManager的SendBlock接口，将数据发送到网络上。接下来的章节我们将讲解当请求数据的节点接收到其他节点发送来的key对应的数据会如何处理。
