3.运行堆栈 | 3. Running the stack

3.1开始

用户可能与其他用户有多个“虚拟”连接。一个MG最多连接一个MGC，而一个MGC可以连接到任意数量的MG。对于每个连接，用户选择传输服务，编码方案和用户回调模块。

MGC必须启动其传输服务，以便听MG试图连接。实际运输如何启动超出了本申请的范围。但是，传输服务必须提供发送句柄（通常是套接字标识或主机和端口），以便我们能够将消息发送到正确的目的地。然而，从我们的角度来看，我们不会假设任何关于这个问题的不透明手柄。希望它相当小，因为它会经常在进程之间传递系统。

用户可以根据Erlang / OTP的应用程序概念在.config文件中进行静态配置，或者以配置设置作为megaco的参数动态启动：start_user / 2。这些配置设置稍后可以使用megaco进行更新：update_conn_info / 2。

函数megaco：connect / 4用于告诉Megaco应用程序应该监控哪个控制进程，远程用户拥有哪个MID，应该使用哪个回调模块发送消息等等。当建立这个“虚拟”连接时，用户可以使用megaco：call / 3和megaco：cast / 3以便将消息发送到另一端。然后由MG在应用一些聪明的算法发送它的第一个服务变更请求消息以便解决启动雪崩的问题（如RFC中所讨论的）。

原始用户将等待回复或超时（由request_timer定义）。当它收到答复时，可以选择确认（由auto_ack规定）并转发给用户。如果收到临时未决答复，则将使用long_request_timer而不是通常的request_timer，以避免虚假的重新发送请求。

在目的地方，传输服务等待消息。每条消息都通过megaco：receive_message / 4回调函数转发到Megaco应用程序。传输服务可能提供或不提供阻止和解除对传入消息的接收的手段。

如果在“虚拟”连接建立之前收到消息，则连接将自动设置。MGC可能是真正开放的，并根据传输层联系的执行方式动态决定使用哪种编码和传输服务。对于IP传输，两个端口是标准化的，一个用于文本编码，一个用于二进制编码。如果例如在文本端口上接收到UDP分组，则可以决定编码和传输。

在解码消息之后，调用各种用户回调函数以允许用户正确操作。有关回调参数的更多信息，请参阅megaco_user模块。

当用户在其回调函数中处理了一个事务请求时，Megaco应用程序组装一个事务回复，使用选定的编码模块对其进行编码，并通过调用回调函数将消息发回：

• SendMod:send_message(SendHandle, ErlangBinary)

重新发送消息，处理未决事务，确认等由Megaco应用程序自动处理，但用户可以通过各种配置可能性自由覆盖默认行为。有关可能性，请参阅megaco：update_user_info / 2和megaco：update_conn_info / 2。

当连接中断时（megaco明确指出：disconnect / 2或控制进程终止时），调用用户回调函数以允许用户重新建立连接。保持消息的内部状态，重新发送定时器等不受此影响。当连接断开时，一些重新发送将失败，但自动重新发送算法不会为此而烦恼，并且最终当连接启动并运行时，如果超时设置为足够长的时间。用户可以选择显式调用megaco：cancel / 2来取消连接的所有消息。

3.2 MGC启动呼叫流程

为了准备MGC接收初始消息，希望服务变更请求需要完成以下工作：

• 启动Megaco应用程序。
• 启动MGC用户。这可以通过megaco明确地完成：start_user / 2，或者通过提供-megaco用户配置参数来隐式完成。
• 启动传输服务并为其提供从megaco获取的接收句柄：user_info / 2。

当初始消息到达时，传输服务将它转发给自动设置连接的协议引擎，并在调用UserMod：handle_trans_request / 3之前调用UserMod：handle_connect / 2，如下所示：

图3.1：MGC启动呼叫流程

3.3 MG启动呼叫流程

为了准备MG发送初始消息，希望服务变更请求需要完成以下工作：

• 启动Megaco应用程序。
• 启动MG用户。这可以通过megaco明确地完成：start_user / 2，或者通过提供-megaco用户配置参数来隐式完成。
• 启动传输服务并为其提供从megaco获取的接收句柄：user_info / 2。
• 使用megaco：connect / 4设置与MGC的连接，并为其提供从megaco：user_info / 2获得的接收句柄。

如果MG已经配置了MGC的MID，则它可以作为RemoteMid参数给予megaco：connect / 4，呼叫流程如下所示：

图3.2：MG启动呼叫流程

如果MG不能配置MGC的MID，则MG可以使用原子'preliminary_mid'作为megaco：connect / 4的RemoteMid参数，呼叫流程如下所示：

图3.3：MG启动呼叫流程（无MID）

3.4配置Megaco堆栈

有三种配置：

• 用户信息 - 与megaco用户有关的信息。读/写。用户是由MID标识的实体，例如MGC或MG。这些信息可以使用megaco:user_info。
• 连接信息 - 有关连接的信息。读/写。这些信息可以使用megaco:conn_info。
• 系统信息 - 全系统信息。只读。这些信息可以使用megaco:system_info。

3.5初始配置

Megaco的初始配置应该在Erlang系统配置文件中定义。为Megaco应用程序定义了以下配置的参数：

• users = [{Mid, [user_config()]}]. 每个用户都由一个元组来表示，用户的Mid和配置参数列表（每个参数又是一个元组：）{Item, Value}。
• scanner = flex | {Module, Function, Arguments, Modules}

-  `flex` will result in the start of the flex scanner with default options.

-  The MFA alternative makes it possible for Megaco to start and supervise a scanner written by the user (see `supervisor:start_child` for an explanation of the parameters).

参见Configuration of text encoding module(s)更多信息。

3.6更改配置

配置可以在运行时更改。这是通过函数megaco:update_user_info和megaco:update_conn_info

3.7交易发送者

事务发送者是一个进程（每个连接一个），它处理所有事务发送，如果这样配置的话（见megaco:user_info和megaco:conn_info）。

交易发送者的目的是积累交易以获得更高效的消息发送。累计的交易是交易请求和交易确认。对于交易确认的好处是非常大的，因为交易很小并且可能有交易范围（这意味着交易1,2,3和4的交易确认可以作为范围1-4在一个交易确认中发送，而不是四个单独的交易）。

有许多配置参数用于控制事务发送者的操作。原则上，在以下情况下，会从进程发送包含所有内容（ack和请求）的消息：

• 当trans_timer到期。
• 当trans_ack_maxcount收到数量的确认。
• 当trans_req_maxcount请求的数量已收到。
• 当所有收到的请求的大小超过trans_req_maxsize。
• 发送回复事务时。
• 发送待处理事务时。

当要发送内容时，除非触发器是回复事务并且回复的大小和所有请求都大于此值，否则所有内容都会打包成一条消息trans_req_maxsize，在这种情况下，存储的事务将首先以单独的消息发送，并且在另一条消息中回复。

当事务发送者收到一个已经“存储”的请求（由事务ID指示）时，它被假定为重发，并且所有存储的内容都被发送。如果没有正确选择trans_timer和的值，可能会发生这种情况request_timer。

3.8交易回复的部分

在megaco标准的第3版中引入了Segmentation软件包。简单地说，这个软件包定义了一个过程，用于在使用不自动执行此操作的传输（例如UDP）时分割megaco消息（事务回复）。另见version3。

虽然在已经做到这一点的传输上使用分段（例如TCP）既没有意义也没有好处，但megaco应用程序不检查这一点。相反，它由用户来正确配置。

• 接收分段消息：

这由megaco应用程序自动处理。然而，有一件事需要由用户配置，segment_recv_timer选项。

请注意，根据使用哪个函数发出原始请求，这些段将以不同方式交付给用户。当使用megaco：cast函数发出请求时，这些段在到达时通过handle_trans_reply回调函数一次传递给用户。但是这显然不适用于megaco：call函数。在这种情况下，分段会累积，然后在函数返回时一次全部交付。

• 发送分段消息：

这也由megaco应用程序自动处理。首先，只有如此配置才会尝试分段，请参阅segment_send选项。其次，megaco依赖于使用的编解码器编码动作应答的能力，这是megaco应用在分割时处理的最小组件。第三，仅当动作应答的大小（加上任意消息头大小）的总和大于指定的最大消息大小（请参阅max_pdu_size选项）时才会对回复进行分段。最后，如果分段被确定，则每个动作回复将构成其自己的（分段）消息。