0、前言在阅读 nanomsg 源码的过程中我逐渐领悟到它的核心设计思想用 C 语言手工实现了一套以内存字段分发的异步事件系统。函数只是解释器真正决定程序走向的是结构体里那些int和函数指针——每次状态切换、每次事件路由都是靠读写内存中的字段来完成而不是靠调用栈。在这个框架里ependpoint端点模块代码量很少却处于一个非常关键的位置——它是 socket 和传输层之间的桥梁。理解它是理解整个 nanomsg 分层架构的钥匙。1、ep 在分层架构中的位置nanomsg 的分层架构如下┌──────────────────────────────────────────┐ │ 协议层 (sockbase) │ │ pub/sub, req/rep, bus, pair, survey... │ │ 负责消息路由、协议语义 │ ├──────────────────────────────────────────┤ │ Socket (nn_sock) │ │ 核心枢纽。持有 eps 链表、sockbase、选项、 │ │ 统计信息。send/recv 在此层做阻塞/超时逻辑 │ ├──────────────────┬───────────────────────┤ │ ep (端点) │ pipe (管道) │ │ 生命周期管理 │ 数据收发通道 │ │ ← 本篇主角 │ ep 不参与数据流 │ ├──────────────────┴───────────────────────┤ │ 传输层 (btcp/ctcp/stcp...) │ │ TCP, IPC, WebSocket, Inproc │ │ 真正的网络 I/O │ └──────────────────────────────────────────┘2、ep 的数据结构structnn_ep{structnn_fsmfsm;// 状态机ep 是 sock 的子 FSMintstate;structnn_sock*sock;// 终身归属的 socket单值指针不共享structnn_ep_optionsoptions;// 从 sock 模板拷贝的选项inteid;// 单调递增的端点 IDstructnn_list_itemitem;// 挂入 sock-eps 链表的节点charaddr[NN_SOCKADDR_MAX1];// 地址字符串intprotocol;// 协议类型实际未被使用活协议在 sock 上intlast_errno;// 最近一次错误码void*tran;// 传输层私有对象指针如 nn_btcp*structnn_ep_opsops;// 传输层操作集虚表};几个值得注意的点sock是单值指针不是链表不是数组。一个 ep 从创建到销毁只属于一个 socket终身不变。反过来一个 socket 的eps链表可以挂多个 ep——这是严格的多对一关系。tran ops就是 C 语言版虚表。void* tran抹平了不同传输类型btcp、ctcp、bipc……的差异ops里存函数指针stop/destroy 等。调用时就是ep-ops.stop(ep-tran)等价于 C 的ep-tran-stop()。3、ep 的 FSM为什么这么简单ep 的 FSM 只有 3 个状态、1 个有效事件nn_fsm_start IDLE ──────────────► ACTIVE ▲ │ nn_fsm_stopped │ (通知 sock 后) │ STOPPING ◄───────────── nn_fsm_stop对应的 handler 也极简staticvoidnn_ep_handler(structnn_fsm*self,intsrc,inttype,void*srcptr){switch(ep-state){caseNN_EP_STATE_IDLE:if(srcNN_FSM_ACTIONtypeNN_FSM_START)ep-stateNN_EP_STATE_ACTIVE;// 启动切到 ACTIVEbreak;caseNN_EP_STATE_ACTIVE:nn_fsm_bad_source(...);// 任何事件都报错break;}}为什么 ACTIVE 状态不接受任何事件因为数据路径根本不经过 ep。之前我们分析过 BUS 协议的数据流转TCP 数据到达 → stcp 的 FSM 处理传输层自己的状态机 → nn_pipebase_received → NN_PIPE_IN → sock-fsm 直接收到事件 ← 绕过了 ep → sockbase-in(pipe)pipe 是传输层创建的pipe 的 FSM owner 直接设为 sock事件直接投递给 sock。ep 在整个数据收发过程中是完全透明的——它只在 bind/connect/stop 时出场。就像我之前总结的“ep 被刻意设计成极简——它就是 socket 和传输层之间的一个注册/注销代理”。建连时负责调用transport-bind/connect断连时负责调用ops.stop/ops.destroy中间的数据流与它无关。复杂的 FSM 留给传输层stcp 有十几个状态处理 TCP 握手、重连、收发、超时ep 保持最小化。4、初始化同步一次性完成intnn_ep_init(structnn_ep*self,intsrc,structnn_sock*sock,inteid,conststructnn_transport*transport,intbind,constchar*addr){// 1. 初始化 FSMep 是 sock-fsm 的子状态机事件向上通知nn_fsm_init(self-fsm,nn_ep_handler,nn_ep_shutdown,src,self,sock-fsm);self-stateNN_EP_STATE_IDLE;// 2. 绑定 socket、ID从 sock 拷贝选项模板self-socksock;self-eideid;memcpy(self-options,sock-ep_template,sizeof(structnn_ep_options));// 3. 存储地址strcpy(self-addr,addr);// 4. 立即调传输层创建私有对象if(bind)rctransport-bind(self);// → nn_btcp_create 等elserctransport-connect(self);// → nn_ctcp_create 等// ↑ 内部会回调 nn_ep_tran_setup(ep, ops, tran)完成 opstran 的装配return0;}transport-bind(self)内部流程以 btcp 为例nn_btcp_create(ep) ├─► malloc nn_btcp ├─► 创建监听 socket ├─► 初始化自己的 FSMctx nn_ep_getctx(ep) sock-ctx共用同一把锁 └─► nn_ep_tran_setup(ep, nn_btcp_ep_ops, btcp) ├─► ep-ops { .stopnn_btcp_stop, .destroynn_btcp_destroy } └─► ep-tran btcp所以nn_ep_init返回时ep 就已经和传输层完全装配好了不需要后续再单独绑定。5、停止流程自底向上的异步清理这是 ep 模块最精巧的部分。由于传输层的关闭是异步的关闭 TCP socket 可能需要等待 FIN 包ep 不能同步销毁必须等传输层回调。于是形成了一条三级回调链nn_ep_stop(ep) │ └─► nn_fsm_stop(ep-fsm) → 进入 shutdown_fn │ ├─► ep-ops.stop(ep-tran) ① 调传输层异步执行 │ (如 nn_btcp_stop → 关闭监听 socket → 等子连接断开...) │ │ ... 传输层异步完成 ... │ └─► nn_ep_stopped(ep) ② 传输层回调 │ │ self-fsm.stopped.fsm self-fsm; (目标ep 自己) │ self-fsm.stopped.type NN_EP_ACTION_STOPPED; │ nn_ctx_raise(...) → 入 events 队列 │ └─► nn_ep_shutdown 收到 NN_EP_ACTION_STOPPED │ ep-state NN_EP_STATE_IDLE; nn_fsm_stopped(ep-fsm, NN_EP_STOPPED); ③ 通知 sock │ └─► sock 收到 NN_EP_STOPPED sock 释放 ep 资源为什么要先通知 ep 自己再通知 sock因为 ep 的 FSM 需要完成状态切换STOPPING → IDLE确保nn_ep_term调用时 ep 确实处于 IDLE 状态。这是一个状态校验点。6、ctx 共享ep 和传输层共用同一个 ctx// btcp.c / ctcp.c传输层初始化根 FSM 时nn_fsm_init_root(self-fsm,handler,shutdown,nn_ep_getctx(ep));// → nn_sock_getctx(sock) → sock-ctx所以整个锁域是sock-ctx ← 唯一的一把互斥锁 / 唯一的事件域 ├── sock-fsm (根状态机) ├── ep-fsm (子状态机owner sock-fsm) └── transport FSM (独立根 FSM但 ctx 指向同一个) └── stcp/usock 等子 FSM同一把锁保护了所有层ctx_enter/ctx_leave同时串行化 sock、ep、transport 的操作。事件通知也全部在同一域内避免了复杂的跨线程同步。7、ep 的错误处理ep 作为传输层和 socket 之间的桥梁还需要负责错误传导voidnn_ep_set_error(structnn_ep*self,interrnum){if(self-last_errnoerrnum)return;// 相同错误不重复报告if(self-last_errno0)nn_sock_stat_increment(self-sock,NN_STAT_CURRENT_EP_ERRORS,1);self-last_errnoerrnum;nn_sock_report_error(self-sock,self,errnum);// 通知 sock 打印/记录}voidnn_ep_clear_error(structnn_ep*self){if(self-last_errno0)return;nn_sock_stat_increment(self-sock,NN_STAT_CURRENT_EP_ERRORS,-1);self-last_errno0;nn_sock_report_error(self-sock,self,0);}传输层遇到错误时调用nn_ep_set_errorep 负责去重、更新统计、上报 sock。错误清除时同理递减计数器。这是 ep 桥梁角色的又一体现——传输层不直接和 sock 交互所有管理类通信都经过 ep。8、总结ep 是什么如果用一句话总结ep 是 socket 和传输层之间的生命周期协调整它不是执行者是指挥者。维度ep 的表现数据收发❌ 完全不参与pipe 直通 sockbind/connect✅ 初始化时同步调用传输层工厂函数stop/destroy✅ 启动异步关闭等待传输层回调通知 sock 收尾错误报告✅ 去重 统计 转发给 sock选项读取✅ 全部代理给 sockFSM 复杂度3 状态、1 事件刻意最小化与传输层的关系通过 opstran 虚表多态编译期擦除类型理解 ep就是理解 nanomsg 分层哲学的一个缩影——每层只管自己最核心的事跨层通信靠内存字段 事件队列 回调链而不是直接的函数调用。当你看到event-fsm owner; event-src self-src; nn_ctx_raise(...)这行代码时记住它不是在调一个函数它是在写一段内存然后等待系统在稍后的某个时刻由某个线程把它取出来喂给另一个状态机。这就是整个框架的底层逻辑。