本协议定义的协议消息可以采用UDP传输。如果对等实体未提供相应的通信端口（参见7.2.8），则协议消息应该被发送至到默认端口： 2944（文本编码）和 2945（二进制编码）。消息响应必须返回至消息发起方使用的端口。
ALF是一种应用层技术，可以通过应用层来影响消息发送至对端实体的方式。一种典型的 ALF是，在应用层使用了消息缓存队列时，允许应用层改变消息发送的顺序。 ALF无具体的规范要求。附件 D.1定义了使用ALF机制的推荐流程。
当协议在使用了应用层成帧功能（ALF）的I P/UDP上进行传送时，应该考虑传送层对于协议最大传送单元（MTU）的限制。
1.1 提供“最多一次”功能
当协议消息在 UDP上进行传输时，可能会发生消息丢失。如果发送的消息无法获得及时响应，则可能导致命令重复发送。命令类型不同，本协议所采用的执行方式也不同。例如 Add命令可能会执行好几遍，从而导致MG的状态无法预知。因此，协议处理进程必须遵循“最多一次”机制。
协议实体应当在各自的内存中保留两个列表，一个用来记录执行完最近所接收到的 TransactionRequest后返回的 TransactionReply，另一个用来记录当前需要处理的事务。当协议实体接收到一个TransactionRequest消息时，它将接收到消息的TransactionID与最近为具有相同MID发出的 TransactionReply响应的TransactionID相比较。两者经过比较后，如果发现 TransactionID相同，则接收方不应执行接收到的事务，而只是重复发送TransactionReply响应消息。如果发现 TransactionID不相同，则接收方将该接收到的TransactionRequest消息与需要处理的事务列表相比较。如果在列表中查找到 TransactionID相同的消息，则表明此TransactionRequest消息为重复发送，接收方不应执行此 TransactionRequest消息（参见D.1.4中TransactionPending发送机制）。
协议处理机制规定了一个长定时器值（ LONG-TIMER），如下所示。其中， LONG-TIMER设定的时间值应该大于一个事务的最大持续时间，该时间还应该考虑事务重复最大次数、重复定时器的最大值以及分组在网络中的最大传输时延。本建议书规定该定时器的参考建议值为30秒。
当协议实体发出响应消息后，如果 LONG-TIMER超时，或者已接收到来自对等实体包含“ Response Acknowledgement Parameter”参数的响应证实消息，则协议实体重复发送的 TransactionReply响应消息应被丢弃。为了检测到并忽略网络中产生的各种重复的 TransactionRequest，当响应消息发出后，协议实体必须为响应消息的TransactionID保存一个备份，保存时间为LONG-TIMER设定的时间。
1.2 事务标识符和三次握手
1.2.1 事务标识符 TransactionID是一个32比特的整数。MGC可以为其控制范围内的每一个 MG预留一个特定的命名空间，或者为其控制范围内同一组所有的MG预留同一个命名空间。MGC可以创建多个独立进程来实现对一个大型MG的操作管理。这些进程应共享一个 TransactionID命名空间。共享方式有多种，例如可以采用事务TransactionID统一分配，或者采用不同的进程预先分配互不重叠的命名空间。具体实现时，应确保每一个逻辑MGC（消息的MID相同）产生的每一个事务必须使用唯一确定的 TransactionID。通过这种方式， MG只需检测TransactionID和MID就可以判断接受到的事务是否为重复发送事务。
1.2.2 三次握手机制
所有消息都可以携带“响应证实参数（Response Acknowledgement Parameter）”参数。该参数携带了一组“已被确认的 TransactionID范围”参数。如果协议实体检测到某个重复 TransactionReply的 TransactionID与“已被确认的 TransactionID范围”参数中所包含的某个 TransactionID相同，则应删除重复的TransactionReply。如果协议实体检测到某些消息的 TransactionID包含在上述 TransactionID范围内，协议实体也应该丢弃这些消息。
如果MG向MGC发送最后一个响应消息后， LONG-TIMER 定时器超时，或者 MG重新进入服务状态，则“已确认的 TransactionID范围”参数必须失效。此后， MG应该继续接受TransactionRequest消息，而不再检测接收到的TransactionID。
包含“Response Acknowledgement Parameter”参数的消息可以以任何顺序进行传送。协议实体必须为接收到的“已确认的TransactionID范围”参数保留至LONG-TIMER定时器超时。
当协议采用二进制编码方式时，如果响应确认消息中包含第一个响应（参见 A.2），则只有一个事务被确认。如果响应确认消息中包含第一个响应确认和最后一个响应确认，则从第一个响应确认到最后一个响应确认的所有 Transaction都被确认。采用文本方式编码时，规定使用一个破折号用来指定某个范围内的TransactionID 全部被确认（参见B.2）。
1.3 计算重传定时器
消息请求的发送方应为所有发送的事务指定一个重传定时器，当重传定时器超时，消息请求的发送方实体仍未接收到消息响应，则应当重复发送该事务。当重复多次发送的事务仍未获得响应时，且从第一次消息发送开始至定时器超时，请求的发送方应当采用其他机制和/或拆除现有或即将建立的连接。
本建议书未对重传定时器数值进行规定。通常重传定时器的数值与特定的网络状况有关。通常，重传定时器应该通过检测发出消息与接收消息响应之间的时间间隔来估计重传定时器数值。具体实现时，发生第一次消息重传后，重传定时器计算算法必须对此后发生的每一次重传的重传定时器数值按指数递增方式进行补偿。
注 —以下是一种适用 TCP/IP传输的重传定时器计算算法，该算法使用以下两个变量：
• 平均确认时延AAD （Average Acknolodgement Delay），该参数是将时延采用指数平滑平均进行估算；
• 平均偏移ADEV（Average Deviation），该参数是将时延与当前平均值之间的绝对差值采用指数平滑平均进行估算。当采用 TCP传输时，重传定时器数值被设置为 AAD与N倍ADEV之和。重传定时器的最大值应该确保在 LONG-TIMER超时后，MG不应再接收到重复的分组。重传定时器最大致的建议参考值为 4秒。
当出现一次消息重传后，协议实体应该遵循以下规则：
• 应该将AAD的估算值加倍。
• 应该以相同概率随机选取0.5AAD到 AAD之间的一个随机值。
• 应该将重传定时器取值设置为上述随机值与N倍ADEV之和。
采用以上规则计算重传定时器有以下两方面的作用：由于包含了一个指数递增单元，当事务处理进程发生拥塞时，将自动降低消息流的速率。此外，由于还包含了一个随机单元，它可以避免由同一外部事件触发的通知消息之间发生同步。
1.4 临时响应
在事务执行过程中，某些事务执行可能需要较长的时间。从而可能会导致事务执行与基于重传定时器的重传进程发生冲突。执行时间太长可能导致事务被重传多次，或者导致重传定时器数值过大而降低传输的效率。如果协议实体已经预见到某一事务需要较长的执行时间，则它可以先发送一个 TransactionPending临时响应消息来指示该事务正在被处理。当协议实体接收到重复的 TransactionRequest消息，如果该事务正在处理，也应该发送TransactionPending消息。
接收到TransactionPending消息的实体必须为TransactionPending消息对应的TransactionRequest消息的重传定时器设定一个不同数值。如果发起TransactionRequest的实体在接收到Transaction Pending消息之后，接收到最终的 TransactionReply消息，则必须立即向对端实体发送一个确认消息，此后，必须重新使用通常的重传定时器。对于发送了 TransactionPending临时响应消息的实体，必须在发送的最终响应中包含一个“immAckRequired（需要立即确认）”字段，通过这一字段来表明该实体希望能够获得一个立即的确认消息。对于同一个 TransactionRequest，实协议体在接收到最终 TransactionReply之后，必须忽略接收的TransactionPending消息。
1.5 请求、响应和证实重复发送
一系列的事务可以完成协议的交互流程，每一个事务都由一个 TransactionRequest和一个 TransactionReply组成，TransactionReply消息通常也被称为响应消息。当使用 UDP传送协议消息时，消息可能发生丢失。如果发送的消息未获得及时响应，事务可能会被重复执行。协议实体应当在各自的内存中保留两个列表，一个用来记录执行最近所接收的事务后返回的事务响应，例如，在最近一次 LONGTIMER超时内所发送的所有事务响应列表，另一个用来记录当前需要处理的事务。
使用重传机制，可以避免发生以下三种差错：
• 传输差错，例如，消息分组由于线路上的噪声或队列的拥塞而发生丢失；
• 协议实体单元故障，例如，消息到达某一协议实体时接口不可用；
• 协议实体故障，例如，整个实体不可用。
协议实体应该可对由于传输差错导致的丢包率进行估算。在合理配置的系统中，分组丢失率应该很低，通常小于 1%。如果一个 MGC或MG必须将某一消息重传多次，导致重传的原因可能是传输差错之外的其他原因。例如，如果丢包率为 1%，则重传5次失败的概率为一千亿分之一。这种情况对于处理能力为 1000事务/秒的MGC来说，应该每 10天最多发生一次。（实际上，这种不正常的重传次数应该是当前丢包率的函数）。通常，可疑重传次数阈值Max1应该低于切断连接的重传次数阈值，后者取值应该更高。
一种典型的重传算法是简单地对连续重传次数进行统计。当某个事务重传次数超过发生一定数目 N（通常7<N<11）以上时，则判定该连接已断开。考虑到可能发生的无法检测或正在进行的“ failover”因素的影响，应对这种算法加以改进，以确保当MG接收到一个表明发生“failover ”的有效 “ServiceChange”消息时，该 MG可以向新的 MGC发送命令消息。而消息响应应仍被送到消息发起的源地址。
为了能对网络负荷进行自适应的调整，定时器应按指数递增。如果定时器的初始值设置为 200微秒，则第五次重传的消息发生丢失将在大约6s后被检测到。如果发生“failover”情况，6s是一个可以接受的等待时延。此后，丢失的重传消息应该在定时器超时后继续重传。采取这种方式可以克服MG与MGC之间瞬时连通性问题，另一方面也可以给执行“ failover”的MGC更多的时间（等待时间为 30秒也是一个可以接受的时间）。
然而，重传等待时间最大值 T-MAX应当是固定的。消息在任何一次重传之前，应该确定第一次消息传送与重传的时间间隔不应超过 T-MAX。如果该时间超过 T-MAX，则MG可以判定MGC已经发生了故障且MGC开始执行故障恢复。此时， MG必须发送带有 ServiceChangeMethod参数等于“ Disconnected”的 ServiceChange消息，以使新的 MGC获知该 MG丢失了一个或多个事务。T-MAX 与LONG-TIMER 有关， LONG-TIMER的数值应为T-MAX 数值与网络最大传输时延之和。
2 采用TCP
本协议中规定的各种消息可以采用 TCP传送。如果对端实体未提供端口（参见 7.2.8），各种消息应该被发送到默认端口上。 TCP是一种基于流的协议，本协议规定可使用各种消息作为消息的传送单元。根据 RFC 1006，必须使用 TPKT来描述TCP流中的各种消息。
对于面向事务处理的协议，TransactionRequest与TransactionReply可能发生丢失。因此，在采用 TCP进行传送时，各种协议实体应为请求和响应指定应用层的定时器，定时器的计算与在UDP/ALF传送类似。
2.1 提供“最多一次”功能
尽管协议在TCP上传输时不会发生传输丢失，但是在实际情况中TransactionRequest或TransactionReply仍可能发生丢失。如果 TransactionRequest未获得及时响应，消息就会被重复传送。命令类型不同，本协议所采用的执行方式也不同，例如Add命令可能会执行好几遍，从而导致 MG的状态无法预知。
为了防止出现消息丢失，建议协议实体使用D.1.1 中描述的规则。
2.2 事务标识符和三次握手机制尽管TCP提供了可靠的传输机制，但是 TransactionReply消息仍然可能发生丢失。所以，当协议在 TCP上传输时，建议各种协议实体应执行D.1.2.2描述的规则。
2.3 计算重传定时器
由于TCP提供了可靠的传输机制，TransactionRequest或TransactionReply发生丢失的概率应该很低。因此，当协议采用TCP进行传输时，只需要使用简单的定时机制。因此在TCP传输中采用的定时机制不应该采用UDP/ALF传输中使用的指数补偿算法，然而，某些实体可能已经实现了指数补偿算法，例如 MGC中，MGC不仅务必实现TCP还务必实现UDP/ ALF。
2.4 临时响应
与UDP上传输一样，在 TCP传输时，某些事务执行可能需要较长的时间。如果协议实体可以预见某一事务需要较长的执行时间，则它可以先发送一个 TransactionPending临时响应消息指示事务正在被处理。当协议实体接收到重复的 TransactionRequest消息，如果该事务正在处理，也应该发送 TransactionPending消息。
接收到TransactionPending消息的实体必须为对端实体指定一个更长的定时器。
在TransactionRequest和TransactionReply被确认以前，协议实体必须保留所有的 TransactionRequest和 TransactionReply消息。处理程序应该遵循附件 D.1.4中的相关规定，唯一不同的是此时定时器应该只选择一个简单的值。当协议实体接收到最后的响应消息后，没有必要立即发送确认消息。
2.5 命令执行顺序
TCP可以支持事务的有序传输。因此在 TCP上进行传输时，不需要使用特殊机制来保证命令顺序传输。应该指出的是，在 ALF/UDP上传输时允许发送方在发生网络拥塞时修改其操作，此时该实体可以对事务进行重新排序。然而，TCP不能实现这种功能。