网络和消息

原文地址:https://docs.corda.net/messaging.html

Corda 在 TLS 之上使用 AMQP/1.0 实现节点间的通信,当前是使用 Apache Artemis,一个可嵌入的 message queue broker 来实现的。构建在创建好的 MQ 协议上给了我们诸如持久化到硬盘,带有 backoff 和 dead-letter routing 的自动重试发送,安全和大的消息流等功能。

Artemis 隐藏在一个轻接口(thin interface)后边,这个接口还具有一个只在内存中存储的实现,这个在单元测试(unit tests)和可视化工具(visualisation tools)可以使用。

未来版本的 Corda 将会允许 MQ broker 可以从主节点中分离出来并且像一个独立的 server 那样运行。我们可能也会支持通过 JMS 的 non-Arteis 实现,允许 broker 能够有其他的实现。

这有很多种方式跟网络进行互动。当编写一个应用的时候,你通常不会直接地使用一个消息子系统。你会将它构建在 flow 框架之上,这会在原始消息(raw messaging)之上添加一层来管理多步的 flows 并且让你思考关于身份(identities)而不是某个特定的网络 endpoints。

网络地图服务 Network Map Service

网络地图服务支持了消息层,它负责跟踪网络中的公共节点。

节点具有一个内部的组件,网络地图缓存,它包括了网络地图的一个副本(只是一个文件)。当一个节点启动的时候,它的缓存会获取整个网络地图的一个副本,并且会请求当网络地图有变化的时候被通知。然后节点会将自己注册到网络地图服务中,这个服务会通知所有订阅的节点有个新的节点加入到网络中来。节点不会自动地将自己从注册中移除,所以当节点由于维护等原因离线之后,他们仍旧会在网络地图中存在,发送给他们的消息会被放入队列中,以最小化造成的损坏。

节点会将签过名的变动发送给网络地图服务,然后会被通知给那些之前请求过要被通知的节点。

网络地图服务当前支持:

消息队列 Message Queues

节点运行的时候会使用不同的消息队列。比较重要的都在下边进行了描述。其他的队列会被用来在维护和其他比较小的一些活动中。

p2p.inbound.$identity:节点会在这个消息队列中监听由其他节点发送过来的消息。只有同一网络中已经授权的节点才会有权限发送消息。在内部路由的消息也会发送到这个队列中(比如一个节点中的两个 flows 互相联系)。

internal.peers.$identity:这些是一系列的私有队列,是节点用来向其他节点发送消息的。队列的名字是以 base 58 加密的目标节点的身份密钥的信息作为结尾。这里基本上是每个 peer 节点一个队列。Broker 会通过网络地图服务来查找 peer 节点的网络地址,然后跟对方节点的 p2p.inbound.$identity 队列建立一个桥连接(bridge)。

internal.services.$identity:这些是节点可能会用来向服务(services)发送消息的私有队列。队列的名字是以 base 58 加密的服务的身份密钥的信息作为结尾。这里每个服务标识(identity)最多是一个队列(但是要注意的是一个服务可能会有多个标识)。Broker 会跟所有的网络中提供服务的节点创建桥连接(bridges)。当跟服务合作方建立一个回话之后,handshake 会被发送到这个队列中来,并且一个对应的桥连接会被用来将消息转发给目标节点的 p2p 队列。当一个 peer 被选择之后,会话将会正常进行。

rpc.requests:RPC 客户端通过该队列发送请求,这个队列也仅仅对被授权为 RPC 用户的客户端才可以访问。

clients.$user.rpc.$random:RPC 客户端被授权使用他们的用户名($user)来创建一个临时的队列,并有权利从这个都列中接收消息。RPC 请求必须要包含一个随机数(random),通过它节点可以构建用户可以监听并且可以向其发送反馈的队列。这个机制能够避免其他的用户能够监听反馈。

安全 Security

客户端尝试连接节点的 broker 会出自四个 groups 之一:

  1. 任何使用用户名 SystemUsers/Node 连接的被认为是运行着 broker 的节点,或者是节点的一个逻辑组件(logical component)。他们所提供的 TLS 证书必须要跟 broker 对于该节点的证书匹配。如果匹配上的话,那么他们会被授权访问所有可用的队列,否则的话会被拒绝访问。
  2. 任何使用用户名 SystemUsers/Peer 连接的被认为是在同一 Corda 网络中的 peer 节点。他们的 TLS root CA 必须同节点的 root CA 相同。Root CA 是网络的 doorman,并且具有相同的 root CA 意味着我们是被相同的 doorman 准入进入到此网络的。如果他们是同一网络的组成节点,那么他们仅仅被授权向我们的 p2p.inbound.$identity 队列发送消息,否则的话会被拒绝。
  3. 任何其他的用户名会被认为是一个 RPC 用户,会根据节点的有效的 RPC 用户列表来进行授权。如果授权成功,那么他们仅仅会给与有效的权力来执行 RPC,否则会被拒绝。
  4. 没有用户名和密码的客户端会被拒绝。

Artemis 提供了一个功能,为每一个收到的消息田间有效的用户的注解(annotating)。这个允许节点的消息服务为系统的其他部分提供被授权的消息。对于上边提到的前两种客户端类型,被验证的用户是客户端的 TLS 证书的 X.500 subject。这个允许 flow 框架来判断初始一个新 flow 的 Party 的权限。对于 RPC 客户端,被验证的用户是指用户名本身,RPC 框架用这个来决定这个用户应该有什么权限。

当连接其他 peer 的时候,broker 也会进行验证。他会检查 TLS 证书 subject 同网络地图服务中记录的 X.500 legal name 相匹配。