如何设计灵活的Erlang协议栈创建API

Question

我对当前的方法不满意，只是尝试重新设计在 Erlang 中构建协议栈的方式。按重要性排序的功能：

1. 性能

2. 添加新协议变体的灵活性和实现速度

3. 探索协议变体将有助于开发从 shell

我当前的模型 (这个问题已经描述了）除了通过函数调用发送（）和通过消息接收的丑陋的不对称性之外，还达到了其极限。

整个协议引擎的整体情况如下所示：

底部：

• 每个堆栈的底部有几个端口，或者有时可能还有一个 gen_tcp（独立通道有多个相同的堆栈，所以我们不能太这里的静态只是注册进程，必须在各处传递 Pids。

• 在端口顶部是由主管管理的一些模块（从系统启动，并且在整个生命周期中没有错误）。

顶部：

• 由事件发生触发（一般意义上不是 event_handler 意义上的）。是面向连接的协议端（例如，具有 connect() 和 close() 语义。

• 协议栈的顶端可能只能动态启动，因为堆叠在一起形成堆栈的模块是动态可配置的，并且可能会随着连接的不同而改变。

• 当前计划将传递一个模块名称列表 + 来自顶层的可选参数，当在堆栈中调用 connect() 时，这些参数将被消耗。

• 顶级进程将被链接，因此当此处出现任何问题时，整个连接都会失败。

模块类型以及它们之间的通信类型

目前为止发现了几种模块：

• 无状态过滤模块

• 有状态的模块，有些适合 gen_server，有些适合 gen_fsm，但大多数可能是简单的服务器循环，因为选择性接收将很有用，并且经常简化代码。

层与层之间的通信类型：

• 独立发送和接收数据包（从外部看来是独立的）

• 发送某些内容的同步调用，阻塞直到有答案，然后将结果作为返回值返回。

• 与多个模块对话的多路复用器（这是我在此处的定义，以方便讨论）

• 具有不同连接点的解复用器（名为 的解复用器与向上的

模块通信。目前，我唯一的解复用器位于堆栈的静态底部，而不是动态创建的顶部。多路复用器目前仅位于顶部。

在我之前链接的问题处理的答案和评论中，我听说 API 通常应该只包含函数而不是消息，除非另有说服力，否则我同意这一点。

请原谅对问题的冗长解释，但我认为它对于各种协议实现仍然具有普遍用途。

我将在答案中写下到目前为止我计划的内容，并且还将解释最终的实现以及我稍后的经验，以便在这里实现一些普遍有用的东西。

Answer 1

我将添加到目前为止我计划的内容作为答案的一部分：

• connect 传递了一个要堆栈的模块列表，在参数的情况下看起来像一个 proplist，例如：

  connect([module1, module2, {module3, [params3]}], param0, future_params)
  

  每一层都剥离头部并调用下一层连接。

• connect()“以某种方式”向上和/或向下层传递有趣的引用

  • 发送异步发送到堆栈将由较低级别的连接返回
  • 用于异步接收堆栈的recv将作为参数传递给较低级别​​的连接
  • 调用同步发送并等待返回的回复 - 不确定如何处理这些，可能也从较低级别的连接返回

• 多路复用器路由列表可能看起来像这些

  connect([模块1, 多路复用器, [[m_a_1, m_a_2, {m_a_3, [param_a_3]}], 
                                  [m_b_1，m_b_2]，
                                  [{m_c_1, [param_c_1]}, m_c_2]], param0, 
                                                                  进一步的参数]）。
  

---

目前我决定不会有用于同步调用的额外函数，我只是使用 send 来实现它。

在这种情况下，对于无状态模块，有一个该想法的实现示例：encode/1 和 decode/1 对数据包进行一些 for 和 back 转换，例如解析二进制表示进入记录并返回：

connect(Chan, [Down|Rest], [], Recv_fun) ->
    {Down_module, Param} = case Down of
                               {F, P} -> {F, P};
                               F when is_atom (F) -> {F, []}
                           end,
    Send_fun = Down_module:connect(Chan, Rest, Param,
                                   fun(Packet) -> recv(Packet, Recv_fun) end),
    {ok, fun(Packet) -> send(Packet, Send_fun) end}.

send(Packet, Send_fun) ->
    Send_fun(encode(Packet)).

recv(Packet, Recv_fun) ->
    Recv_fun(decode(Packet)).

一旦我有了一个有状态的示例，我也会将其发布。