Mojo

分为清晰分离的层#xff0c;子组件的基本层次结构如下#xff…Mojo简介

Mojo

格式以及具有针对多种目标语言的代码生成的绑定库以便于跨任意进程间和进程内边界传递消息。

Mojo

笔者在阅读源码前喜欢会去思考“如果让我来设计一个类似的功能的模块我会怎么设计”。

然后对比文档去思考为什么会出现思路的差异这种方式可以让我快速掌握一个开源库的设计精髓。

这次也是一样我们想想如果是我们自己设计Mojo这会是什么样的架构和过程。

首先Mojo是跨平台的那么必然有一层platform的平台差异屏蔽层其次跨进程通信在不同平台上的最佳实现方案可能不一样例如有的平台是管道有的平台是共享内存具体如何选择取决于不同平台的性能差异因此我必须将跨平台通信细节进行抽象提取出一些概念用于描述通信的应用层细节。

之后两个进程之间的通信之前需要先建立连接因此必然也需要定义一组规则和概念来描述连接的应用层细节。

为了增加通信的灵活性我们可以定义一组观察者或者过滤器的规则可以实现对数据流的监测和量化也能实现更灵活的扩展。

因此我们需要定义一组规则和概念来实现这个目标。

为了让跨平台通信框架更加易于使用我们需要提供一套序列化和反序列化的框架这样可以让通信以自定义结构体的形式进行而非数据流。

如果存在大量的通信消息那么我们需要解决不同进程共享头文件使用自定义结构体的形式另外Mojo除了跨平台还需要夸语言那么我们必然不能使用某种语言的结构体定义形式例如C的结构体或者JavaScript友好的Json而是需要定义一种新的规则通过工具自动生成不同语言友好的结构体源码。

上面的5和6本质上可以看作是同一个问题并且我首先想到的是protobuffer库可以实现这两个问题的解法。

源码目录体积一览

源码重要文件一览排除test源文件按大小排序top的文件如下图

一般来说体积大的源文件表示的功能都比较核心因此这些文件里面对应的功能和概念很大概率是Mojo框架的核心值得每一项进行标注理解。

在Mojo中的源码中可以很明显的发现关键字Channel是最底层跨进程通信的关键概念并且能找到平台相关的抽象和实现直接搜索文件名关键字就一览无余了

channel.h

看了一眼mojo\core\channel.h可以发现抽象基类是mojo::core::Channel,

message

不同平台通过继承抽象基类mojo::core::Channel实现平台相关的读写以mojo\core\channel_win.cc的ChannelWin为例使用Win32API的ReadFile、WriteFile从base::win::ScopedHandle句柄中读写数据这个句柄是构造函数的参数ConnectionParamsTakeEndpoint().TakePlatformHandle().TakeHandle()传入的获取的。

PlatformChannel

是一个封装了两个交织在一起的端点的类或结构这些端点属于特定平台的基本通信原语比如在Windows上是管道在Unix系统上是域套接字在macOS上是Mach端口对。

其中一个端点被指定为“本地”端点由创建它的进程保留另一个端点被指定为“远程”端点应当传递给外部的进程。

PlatformChannel

IPC一种进程间通信机制。

通常情况下另一个进程是当前进程的子进程PlatformChannel

提供辅助方法来将端点以这种方式传递给子进程但这种设置在所有平台上并不是强制性的。

如果需要一个允许客户端通过名称来连接的通道比如一个命名管道或者套接字服务器这种类型仅在Windows和POSIX系统上被支持那么可以参考

这个类负责持有一个

实例并监听一个单一的来自客户端的连接请求。

这个类不是线程安全的必须在运行I/O消息泵Message

和PlatformChannel

则是在服务端监听和接受这些通道上的连接请求。

PlatformChannel

PlatformHandle平台句柄类它带有一些额外的类型信息用来表明它是一个通道端点channel

MOJO_INVITATION_TRANSPORT_TYPE_CHANNEL

结合调用堆栈

通过调用堆栈可以发现Channel的概念几乎是Mojo最底层的概念了往上走有Router、InterfaceEndpointClient、Message、ChannelMojo概念等。

以下是从最底层到更高层的一些核心概念及其作用的介绍

Channel:

系统中最底层的抽象。

它代表了一个底层的通信通道负责在两个进程之间传输原始的字节数据。

Channel

IPC

API。

它负责序列化和反序列化消息保证数据的完整性并处理底层的传输细节。

Router:

还管理消息的生命周期确保消息按照正确的顺序发送和接收并可能处理流控制和重试逻辑。

Mojo

接口都有一个或多个方法这些方法对应于可以通过该端点发送的消息类型。

InterfaceEndpointClient

会序列化这些方法调用为消息并将它们传递给

系统中传递的一个消息实体。

它通常包含要传输的数据例如方法调用的参数以及可能的元数据例如消息类型或优先级。

在

Mojo

系统的框架其中每个层次都建立在下一个层次之上提供了逐步更高级别的抽象和功能。

开发者可以根据需要选择在哪个层次上与

IPC

在源码一览中我们发现node.cc是最大的源文件我们以此为线索展开对Node的理解和阅读Node相关文件有

Node.h中NodeChannel是一个核心注释只有一句Wraps

Channel

base::RefCountedDeleteOnSequenceNodeChannel,public

Channel::Delegate

的基础上进行了进一步的封装和抽象化。

NodeChannel用于定义

Mojo

中与连接、广播、中介Broker、消息传输以及错误处理相关的实现细节。

如果用计算机网络的术语进行类比那么

Channel

从上面代码中我们发现NodeChannel中有个重要的嵌入类Delegate。

Delegate的概念在chromium广泛存在其实可以理解为Delegate就是一组回调在宿主对象处理逻辑的关键节点时通过Delegate回调转移执行绪以实现行为的定制和扩展的能力。

通过了解Delegate回调的函数组成可以快速了解宿主类的主要功能和关键流程是阅读源码的重要技巧。

例如NodeChannel的Delegate的类定义如下

class

client_name,base::ProcessHandle

process_handle)

destination,Channel::MessagePtr

message)

source_node,Channel::MessagePtr

message)

0;};通过这个代理类就能很直观地理解NodeChannel的功能和作用。

在阅读NodeChannel类的时候有一个关键字出现了多次那就是port。

在Mojo中port是一个命名空间也是一个重要概念port这个类的头文件注释如下

Mojo

系统中“Port”本质上是一个地址的循环列表中的一个节点。

为了本文档的目的这样的列表将被称为“路由”route。

路由是所有

Node

State这些状态决定了它们如何响应以它们为目标的系统事件。

在最简单和最常见的情况下Ports

Ports

的共轭在初始创建时也是它的对端但由于代理这种关系可能随着时间而改变。

PortLocker

通过头文件注释感觉似懂非懂看看Port这个类的主要成员和方法吧

Port

系统中的一个核心组件它代表了消息传递路径上的一个节点。

这个类继承自

base::RefCountedThreadSafePort允许它在多个线程中安全地共享和管理其生命周期。

以下是

Port

kUninitialized未初始化、kReceiving接收中、kBuffering缓冲中、kProxying代理中和

成员变量存储当前

的上一个端口用于验证发送方节点是否有权限发送消息到这个端口同时保持接收消息的顺序。

pending_merge_peer

成员变量标记这个端口是否准备合并。

一系列的序列号成员变量next_control_sequence_num_to_send、next_sequence_num_to_send

等用于跟踪控制和用户消息事件的序列号。

message_queue

成员变量存储该

状态时暂存即将发送的控制消息。

send_on_proxy_removal

成员变量附加到

状态变化的观察者接口。

remove_proxy_on_last_message

peer_closed

Port设置初始的序列号。

AssertLockAcquired

Port

方法检查给定的事件是否应该根据序列号和发送方节点接下来处理。

NextEvent

方法将事件缓存以供后续处理。

TakePendingMessages

方法清空等待节点验证的事件队列并返回所有用户事件。

私有析构函数

~Port确保

系统中作为消息的发送和接收点管理消息的顺序和状态并确保消息在正确的路径上流动。

结合其他源码发现Port和Dispatcher相关逻辑结合紧密另外Port存储了Event的序号等数据信息支持插入事件并且许多数据成员用于Node.cc中实现消息处理可见Port这个类做的事情确实很难和已有的概念类比出来也难怪通过这个类的注释难以一下理解其作用。

简而言之Port这个类即负责一部分事件排序和派发相关的逻辑处理也承载了一个寻址的功能。

Mojo

通常代表了一个独立的参与者如一个进程它是消息传递路径上的一个物理节点。

Node

Node

内部的逻辑上的虚拟节点它负责管理消息的复杂路由、转发以及过滤等操作。

每个

Port

之所以这样设计是为了让两个Node之间可以出现多个连接每个连接就是一对“共轭”的Port。

这样每个连接各自的序号seq就不会互相干扰。

所以序号的数据就存储在Port类里这也就不奇怪了。

正因为Port代表了连接所以数据的过滤和代理也必须面向连接进行因此Port也和相关的类紧密联系。

说实话如果把Port改名为Connection也许会更直观一些。

Name也顺便看看定义

COMPONENT_EXPORT(MOJO_CORE_PORTS)

PortName

COMPONENT_EXPORT(MOJO_CORE_PORTS)

NodeName

接下来我们继续阅读Mojo模块的代码。

了解消息的过滤和派发、序列化和反序列化、Mojom、等功能逻辑。

未完待续…