WO2004045146A1 - Procede de realisation d'une transmission fiable d'un mecanisme de transaction d'un automate fini - Google Patents

Procede de realisation d'une transmission fiable d'un mecanisme de transaction d'un automate fini Download PDF

Info

Publication number
WO2004045146A1
WO2004045146A1 PCT/CN2003/000788 CN0300788W WO2004045146A1 WO 2004045146 A1 WO2004045146 A1 WO 2004045146A1 CN 0300788 W CN0300788 W CN 0300788W WO 2004045146 A1 WO2004045146 A1 WO 2004045146A1
Authority
WO
WIPO (PCT)
Prior art keywords
transaction
state
event
received
response
Prior art date
Application number
PCT/CN2003/000788
Other languages
English (en)
French (fr)
Inventor
Rui Zhao
Original Assignee
Huawei Technologies Co., Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co., Ltd filed Critical Huawei Technologies Co., Ltd
Priority to AU2003271019A priority Critical patent/AU2003271019A1/en
Publication of WO2004045146A1 publication Critical patent/WO2004045146A1/zh

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/90—Buffering arrangements

Definitions

  • the present invention relates to the field of communication technologies, and in particular, to a method for achieving reliable transmission of transactions on an IP network.
  • the MCC controls the media gateway (MG) through the media gateway control protocol (H.248).
  • the H. 248 protocol is a master-slave protocol, which is mainly based on the media gateway controller, the media gateway is the slave, and the media.
  • the gateway controller is responsible for controlling the call status related to the media gateway, and the media gateway controls the media gateway controller. After completing the conversion of the media format between different networks, if the message sent by the media gateway controller does not get a timely response, it may result in repeated sending, which will cause the state of the media gateway to execute the command unpredictable.
  • the protocol messages defined by the H.248 protocol can be transmitted over User Datagram Protocol (UDP) or Transmission Control Protocol (TCP).
  • UDP User Datagram Protocol
  • TCP Transmission Control Protocol
  • message loss may occur.
  • TCP Although TCP Provides a reliable transmission mechanism, but because TCP is a stream-based protocol, for the transaction-oriented H.248 protocol, the transaction request and response transactions in the message
  • the H.248 protocol specifies that the following mechanisms are required for transmission over IP:
  • the protocol entity is required to keep two lists in memory, one is used to record the Transaction Reply returned after the most recently received Transaction Reques t is executed, and the other is used to record the Transaction Request that currently needs to be processed.
  • a Transaction Request message is received Comparing the transaction number (Transaction ID) of the received transaction with the transaction number (Transaction ID) of the most recently issued Transaction Reply. If they are the same, the received request transaction is not executed, and the Transact ion Reply response message is sent repeatedly. If they are not the same, compare the Transaction ID of the received transaction with the Transaction Request table to be processed. If a transaction with the same Transaction ID is found in the list, it indicates that the Transaction Request is sent repeatedly and does not need to be executed.
  • the protocol entity that issued the Transaction Request should specify a retransmission timer for all transactions. When the timer expires and no response is received, the transaction should be sent repeatedly. When the transaction that has been sent multiple times has not received a response, the request is sent.
  • the entity should adopt alternative services or tear down existing or upcoming connections.
  • Transact ion some Transaction execution may take a long time, which may cause the Transaction execution to conflict with the retransmission mechanism. If the execution time is too long, it may cause the transaction to be retransmitted multiple times or the retransmission timer. The value is too large to reduce the transmission efficiency. If the protocol entity foresees that a transaction requires a longer execution time, it may first send a temporary response message (Transaction Pending) indicates that the Transaction is being processed. When the protocol entity receives a duplicate Transaction Request message, if the Transaction is being processed, it should also send a Transaction Pending message.
  • Transaction Pending temporary response message
  • the entity receiving the Transaction Pendin message should be the The retransmission timer is set to a different value; if the final Transaction Reply message is received, an acknowledgement message should be sent immediately to the peer entity, after which the usual timer should be used. For the same Transaction Request, after receiving the final Transaction Reply, the entity shall ignore the received Transaction Pending message.
  • the time set by LONG-TIMER should be greater than the maximum duration of a transaction. This time should also take into account the maximum number of transaction repetitions, the maximum value of the repetition timer, and the maximum transmission delay of the packet in the network.
  • the protocol entity When the protocol entity sends a response message, the protocol entity should save a backup for the transaction ID of the response transaction, and the save time is the time set by LONG-TIMER. If the LONG-TIMER times out, or has received a response confirmation message from the peer entity containing the "Response Acknowledgement Parameter" parameter, which carries a set of "Confirmed Transact ion ID range" parameters, the protocol entity will detect the Transaction Reply list, discard those Transaction Reply whose transaction ID is in the above range.
  • the technical problem to be solved by the present invention is to overcome the disadvantages of the complicated mechanism of realizing reliable transmission of transactions and the difficulty in controlling the implementation of the test, and to provide a simple and clear logical relationship that makes the reliable transmission of transactions complex and easy to implement and test. Methods.
  • This method for realizing reliable transmission of transactions by using a state machine mechanism is characterized in that: a request transaction (Transaction Request) sent by a protocol entity to a counterpart entity is stored in a request queue, and a request received from the counterpart entity is stored The transaction (Transaction Reply) responded by the transaction (Transaction Request) is saved to the Response queue, and the transactions in the two queues respectively complete the corresponding operations and state changes according to the event that triggers the state change, thereby using the state Mechanism for reliable transmission of transactions.
  • the status of the transaction includes:
  • State b The request transaction sent to the peer entity did not receive a response within the time period, and the request transaction was resent one or more times;
  • the event that triggers a transaction status change in the request queue includes:
  • Event a received a response to the request transaction from the peer entity
  • Event b received a temporary response to the request transaction from the peer entity;
  • Event C the retransmission timer of the requested transaction expires;
  • Event d The request transaction has reached the maximum number of retransmissions.
  • the operation state and event change of the transaction are: when event a is received and the current state is state a: the transaction is discarded from the request queue; when event a is received, the current state is state b : Discard the transaction from the request queue; when event a is received and the current state is state c: discard the transaction from the request queue and send a confirmation message to the peer entity;
  • the status of the transaction in the response queue includes:
  • State A The request transaction of the peer entity is received for the first time
  • State B the response to the received request transaction has been sent to the peer entity
  • state C the acknowledgement response from the peer entity to the response transaction
  • the event that triggers a transaction status change in the response queue includes:
  • Event A A request transaction was received from the peer entity
  • Event B Acknowledgment response from the correspondent entity to the response transaction
  • Event C The transaction ID (Transact ion ID) of the response sent to the peer entity is overtime.
  • the change of the status of the transaction and the operation of the event is: when event A is received and the current status is state A: a temporary response is sent to the peer entity, the request transaction is not executed, and the temporary response is resent to Delete the response transaction from the response queue after a certain number of times;
  • the present invention uses the state machine to implement reliable transmission of transactions according to the mechanism specified in the H.248 protocol, and uses the state machine mechanism to design queues, states, and events.
  • the invention makes the transaction reliably transmit complex logical relationships through the design of states and events to become simple and clear, which is easy to implement and test. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS The present invention will be further described in detail according to the embodiments below.
  • the present invention uses the state machine to implement reliable transmission of transactions based on the H.248 protocol's provisions on transmission over IP.
  • the detailed description is as follows:
  • the request transaction (Transaction Request) sent by the entity to the peer entity is saved to a Request queue, and the response transaction (Transaction Reply) in response to the request transaction (Transaction Request) received from the peer entity is saved to a response (Response) queues, and the transactions in the two queues respectively complete the corresponding operations and state changes according to the events that trigger state changes, and use the state machine mechanism to achieve reliable transmission of transactions.
  • Table 1 Status number Status name Status description a TS-SENT Transaction is sent to the peer entity for the first time
  • the transaction sent by the TS-RESENT to the peer entity did not receive a response within the time b, and the transaction was resent one or more times.
  • TS_PENDING—RECEI receives c VED after sending a transaction to the peer entity to the peer entity's temporary response to the transaction Transaction Pending
  • the condition for a Transaction to enter the Request queue is that after it is first sent to the peer entity, the initial state is state a. All possible events that trigger the above state changes include: Table 2 Event number Event name Event description
  • TS— PENDING— REC discards the transaction from the request P person ⁇ 'J EIVED and sends a confirmation message to the peer entity
  • TS-SENT sets the value of the retransmission timer of the transaction to the value of the temporary response timer
  • Transaction's status moves to TS-PENDING— RECEIVED TS-RESENT sets the value of the transaction retransmission timer to the value of the temporary response timer and the number of retransmissions is set to zero
  • TS— RESENT takes alternative services or tears down existing connections or
  • the condition for the Transact ion to enter the Response queue is that the Transact ion Reques t of the peer entity is received for the first time, and the initial state is State A. Once the Transact ion Reply is responded, the response team ⁇ 'J holds the Transact ion Reply, and the state transitions Go to state B and start the long timer LONG_TIMER. All possible events that trigger the above state changes are shown in Table 5, including:
  • the state machine mechanism is used to design the queue, state, and event. Compared with the existing implementation manner, the transaction transact ion reliably transfers complex logical relationships into a single, clear, and easy to implement and test.

Description

一种利用状态机机制实现事务可靠传输的方法 技术领域
本发明涉及通信技术领域， 尤其涉及一种实现事务在 IP网络上 可靠传输的方法。
背景技术
在下一代网络中和软交换组网体系结构中， 媒体网关控制器
( MGC )通过媒体网关控制协议 (H.248 )来控制媒体网关（ MG )。 H.248 协议是一种主从协议， 以媒体网关控制器为主， 媒体网关为从， 媒体. 网关控制器负责对和媒体网关相关的呼叫状态进行控制 ,媒体网关在 媒体网关控制器的控制下完成不同网络之间媒体格式的转换，若媒体 网关控制器发送的消息不能获得及时响应， 可能导致重复发送， 将导 致对媒体网关执行命令后的状态无法预知。
H.248 协议定义的协议消息可以在用户数据报协议 (UDP)或传 输控制协议 (TCP)上传输， 当在 UDP上进行传输时， 可能会发生消 息丟失， 在 TCP上进行传输时， 尽管 TCP提供了可靠的传输机制， 但 由于 TCP是一种基于流的协议，对于面向事务（Transaction)的 H.248 协议， 消息中的请求事务 （Transaction Request ) 与应答事务
(Transaction Reply)仍有可能发生丢失， 所以 H.248协议规定了 在 IP上传输的要求， 保证事务（Transaction) 的可靠传输。
目前， H.248协议规定了在 IP上传输要求遵循以下机制：
(一） "至多一次机制" 要求协议实体在内存中保留两个列表，一个用来记录执行完最近 所接收的 Transaction Reques t后返回的 Transaction Reply, 另一 个用来记录当前需要处理的 Transaction Request, 当接收到一个 Transaction Request消息时，将接收事务的事务号（ Transaction ID ) 与最近发出的 Transaction Reply的事务号 （ Transaction ID )相比 较， 如果相同， 则不执行接收到的请求事务 Transaction Request, 仅重复发送 Transact ion Reply响应消息， 如不相同， 则将该接收事 务 Transaction ID与需要处理的 Transaction Request歹l表相比较， 如果在列表中查找到 Transaction ID 相同的事务， 则表明此 Transaction Request为重复发送， 不必执行。
(二） 重传机制
发出 Transaction Request的协议实体应为所有的 Transaction 指定一个重传定时器， 当定时器超时仍未接收到响应， 则应当重复发 送该 Transaction,当重复多次发送的 Transaction仍未得到响应时， 发送请求的实体应当采取替代服务或拆除现有连接或即将建立的连 接。
(三）三次握手机制
Transact ion执行过程中， 某些 Transaction执行可能需要较长 的时间， 从而可能会导致 Transaction执行与重传机制发生冲突， 执 行时间太长可能导致 Transaction的反复重传多次，或者导致重传定 时器数值过大而降低传输的效率。 如果协议实体预见某一 Transaction需要较长的执行时间， 则可以先发送一个临时响应消息 (Transaction Pending)指示 Transaction正在处理； 当协议实体 接收到重复的 Transaction Request消息， 如果该 Transaction正在 处理， 也应当发送 Transaction Pending消息， 接收到 Transaction Pendin 消息的实体应当为该消息对应的 Transaction Request消息 的重传定时器设定一个不同数值； 如果接收到最终的 Transaction Reply消息， 则应立即向对端实体发送一个确认消息， 此后， 应使用 通常的定时器。 对于同一个 Transaction Request, 实体在接收到最 终的 Transaction Reply后，应忽 矣收的 Transaction Pending消息。
(四）其它
长定时器 （LONG- TIMER):
LONG-TIMER设定的时间应大于一个 Transaction的最大持续时 间， 该时间还应考虑 Transaction最多重复次数、 重复定时器的最大 值以及分组在网络中的最大传输时延。 当协议实体发出响应消息后， 协议实体应为响应事务的 Transaction ID保存一个备份， 保存时间 为 LONG-TIMER设定的时间。 如果 LONG- TIMER超时， 或者已经收到来 自对等实体包含 "Response Acknowledgement Parameter"参数的响 应证实消息，该参数携带了一组 "已被确认的 Transact ion ID范围" 参数， 则协议实体将检测 Transaction Reply 列表， 丢弃那些 Transaction ID包含在上述范围内的 Transaction Reply。
以上协议规定的实现 Transaction可靠传输的机制复杂，对实现 的测试也难以控制。 发明内容
本发明所要解决的技术问题是：克服现有的实现 Transaction可 靠传输的机制复杂以及对实现的测试难以控制的不足， 提供一种使 Transaction可靠传输复杂的逻辑关系变得简单清晰， 便于实现和测 试的方法。
本发明为解决上述技术问题所采用的技术方案为：
这种利用状态机机制实现事务可靠传输的方法， 其特征在于： 将 协议实体向对端实体发送的请求事务（Transaction Request )保存 到请求 （ Request ) 队列， 将对从对端实体接收到的请求事务 ( Transaction Request )所响应的应答事务 ( Transaction Reply ) 保存到应答 (Response) 队列， 两个队列中的事务 (Transaction) 分别根据触发状态变化的事件而完成相应的操作和状态变化，从而利 用状态机机制实现对事务（Transaction) 的可靠传输。
所述的请求队列中， 事务的状态包括：
状态 a: 请求事务第一次被发送给对端实体；
状态 b:发送给对端实体的请求事务在定时时间内没有收到响应， 该请求事务被重发一次或多次；
状态 c: 在向对端实体发送请求事务后接收到对端实体对该请求 事务的临时响应 ( Transaction Pending )。
所述的触发请求队列中事务状态变化的事件包括：
事件 a: 从对端实体接收到对请求事务的响应；
事件 b: 从对端实体接收到对请求事务的临时响应； 事件 C : 请求事务的重传定时器超时；
事件 d: 请求事务达到了最大重传次数。
所述的请求队列中， 事务的状态与事件的操作变化为： 当接收到事件 a，当前状态为状态 a时：将事务从请求队列中丢弃； 当接收到事件 a ,当前状态为状态 b时：将事务从请求队列中丢弃； 当接收到事件 a , 当前状态为状态 c时： 将事务从请求队列中丟 弃， 向对端实体发送一个确认消息；
当接收到事件 b , 当前状态为状态 a时： 将事务的重传定时器的 值设置为临时响应定时器取值，重传次数置零，事务的状态迁至状态 c;
当接收到事件 b， 当前状态为状态 b时： 将事务的重传定时器的 值设置为临时响应定时器取值，重传次数置零，事务的状态迁至状态 c;
当接收到事件 b , 当前状态为状态 c时： 不操作；
当接收到事件 c , 当前状态为状态 a时： 重新发送一次该事务， 重传次数增加， 事务的状态迁至状态 b;
当接收到事件 c， 当前状态为状态 b时： 重新发送一次该事务， 重传次数增加；
当接收到事件 c , 当前状态为状态 c时： 重新发送一次该事务， 重传次数增加，将事务的重传定时器重新设置，事务的状态迁至状态 b;
当接收到事件 d , 当前状态不会为状态 a;
当接收到事件 d， 当前状态为状态 b时： 采取替代服务或拆除现 有连接或即将建立的连接；
当接收到事件 d , 当前状态不会为状态 c。 所述的应答队列中， 事务的状态包括： .
状态 A: 第一次接收到对端实体的请求事务；
状态 B: 对接收到的请求事务的响应已发送给对端实体； 状态 C : 接收到对端实体对应答事务的确认响应 （Response
Acknowledgement )。
所述的触发应答队列中事务状态变化的事件包括：
事件 A: 从对端实体接收到请求事务；
事件 B: 从对端实体接收到对应答事务的确认响应；
事件 C: 向对端实体发送响应的事务号 （Transact ion ID )保存 时间超时。
所述的应答队列中， 事务的状态与事件的操作变化为： 当接收到事件 A， 当前状态为状态 A时： 发送一个临时响应给对 端实体， 不执行该请求事务， 临时响应重发达到一定次数后将应答事 务从应答队列中删除；
当接收到事件 A, 当前状态为状态 B时： 重新发送一次应答事务 给对端实体， 不执行该请求事务；
当接收到事件 A, 当前状态为状态 C时： 不执行该请求事务； 当接收到事件 B, 当前状态为状态 A时： 不操作；
当接收到事件 B, 当前状态为状态 B时： 将应答事务从应答队列 中删除， 仅保存事务号， 事务的状态迁至状态 C;
当接收到事件 B, 当前状态为状态 C时： 不操作；
当接收到事件 C, 当前状态不会为状态 A; P T/CN2003/000788 一 7—
当接收到事件 C, 当前状态为状态 B时： 将应答事务从应答队列 中删除， 丟弃相应的事务号； 当接收到事件 C, 当前状态为状态 C时： 丟弃相应的事务号。 本发明的有益效果为：本发明根据 H.248协议规定的机制利用状 态机来实现 Transaction的可靠传输， 利用状态机机制纣队列、状态 和事件进行设计， 与现有的实现方式相比， 本发明使 Transaction可 靠传输复杂的逻辑关系通过状态和事件的设计变得筒单清晰，便于实 现和测试。 具体实施方式 下面根据实施方案对本发明作进一步详细说明： 本发明基于 H.248协议对在 IP上传输的规定， 采用了状态机来 实现事务（Transaction) 的可靠传输， 详细描述如下： ■ 将协议实体向对等实体发送的请求事务（ Transaction Request ) 保存到一个请求（Request) 队列， 将对从对等实体接收到的请求事 务 ( Transaction Request )所响应的应答事务 (Transaction Reply) 保存到一个应答（ Response )队列 ,两个队列中的事务（ Transact ion ) 分别才艮据触发状态变化的事件而完成相应的操作和状态变化，利用状 态机机制实现对事务（Transaction) 的可靠传输。
Request队列中的 Transaction的状态如表 1所示： 表 1 状态号 状态名称 状态描述 a TS-SENT Transaction 第一次被发送给对端实体
TS-RESENT 发送给对端实体的 Transaction在定时 b 时间内没有收到响应， 该 Transaction 被重发一次或多次
TS一 PENDING— RECEI 在向对端实体发送 Transaction后接收 c VED 到对端实体对该 Transaction 的临时响 应 Transaction Pending
Transaction进入 Request队列的条件是第一次向对端实体发送 后， 初始状态为状态 a。 触发以上状态变化的所有可能事件包括: 表 2 事件号 事件名称 事件描述
TE— RESPONSE—INCOMING 从对 端 实 体接 收到 对 a
Transaction的响应
TE— PENDING— INCOMING 从对端 实 体接收到 对 b
Transaction的临时响应
TE-RESEND-TIMEOUT Transaction 的重传定时器 c
超时
TE— MAX— RETRY— ACHIEVED Transaction 达到了最大重 d
传次数 · 当前 Request队列中的 Transact ion根据触发事件的相应操作和 状态变化情况如表 3所示： 表 3 接收到的事件 当前状态 操作和状态变化
TS-SENT Transaction λλ Request队歹)中 丢弃
TS— RESENT 将 Transaction从 Request队歹' J中
TE— RESPONSES
丢弃
NC0MING
TS— PENDING— REC 将 Transaction从 Request P人歹 'J中 EIVED 丢弃 向对端实体发送一个确认消息
TS-SENT 将 Transaction的重传定时器的值 设置为临时响应定时器取值
TE— PENDING— IN
重传次数置零
COMING
Transaction 的 状 态 迁 至 TS-PENDING— RECEIVED TS-RESENT 将 Transaction的重传定时器的值 设置为临时响应定时器取值 重传次数置零
Transaction 的 状 态 迁 至 TS— PENDING— RECEIVED
TS_PENDING_REC 不操作
EIVED
TS-SENT 重新发送一次该 Transaction 重传次数增加
Transaction 的 状 态 迁 至 TS-RESENT
TS-RESENT 重新发送一次该 Transaction 重传次数增加
TE_RESEND_TI TS-PENDING_REC 重新发送一次该 Transaction MEOUT EIVED 重传次数增加
Transaction的重传定时器重新 设置
Transaction 的 状 态 迁 至 TS-RESENT TS一 SENT 不会发生
TS— RESENT 采取替代服务或拆除现有连接或
TE— MAX— RETRY—
即将建立的连接
ACHIEVED
TS— PENDING— REC 不会发生 EIVED
Response P人歹)中的 Transact ion的^^态 ^口表 4所示： 表 4
Figure imgf000013_0001
Transact ion进入 Response队列的条件是第一次接收到对端实 体的 Transact ion Reques t , 初始状态为状态 A , 一旦响应了 Transact ion Reply, Response队歹' J中保存的是 Transact ion Reply, 状态迁至状态 B， 并启动长定时器 LONG_TIMER。 触发以上状态变化的所有可能事件如表 5所示， 包括:
表 5
Figure imgf000014_0001
当前 Response队列中的 Transaction根据触发事件的相应操作 和状态变化情况如 6所示：
表 6
接收到的事件 当前状态 操作和状态变化
RS一 REQUEST— REC 发送一个 Transaction Pending EIVED 临 时 响 应 给 对 端 实 体
RE— REQUEST— IN (Transaction Pending重发达到 COMING 一定次数后将 Transaction Reply 从 Response队列中删除 ) 不执行该 Transaction Request RS— SENT 重新发送一次 Transaction Reply 给对端实体 不执行该 Transaction Request
RS— RESPONSE— AC 不执行该 Transaction Request K-RECEIVED
RS-REQUEST-REC 不操作 EIVED
RS-SENT 将 Transaction Reply 从 Response 队列中删除， 仅保存
RE-RESPONSE-A
Transaction ID
CK_ INCOMING
Transaction 的 状 态 迁 至 RS-RESPONSE-ACK_RECEIVED
RS— RESPONSE— AC 不操作 K-RECEIVED
RS-REQUEST-REC 不会发生 EIVED
RS-SENT 将 Transaction Reply 从
RE_L0NG_TIME0
Response队列中删除
UT
丟弃相应的 Transaction ID
RS— RESPONSE— AC 丢弃相应的 Transaction ID .RECEIVED 本发明的上述方案， 利用状态机机制对队列、状态和事件进行设 计， 与现有的实现方式相比， 使事务 Transact ion可靠传输复杂的逻 辑关系变得筒单清晰， 便于实现和测试。

Claims

权 利 要 求
1.一种利用状态机机制实现事务可靠传输的方法， 其特征在于： 将协议实体向对端实体发送的请求事务（Transaction Request)保 存到请求 （Request ) 队列， 将对从对端实体接收到的请求事务
(Transaction Request )所响应的应答事务 (Transaction Reply) 保存到应答 (Response) 队列， 两个队列中的事务 (Transaction) 分别才艮据触发状态变化的事件而完成相应的操作和状态变化，从而利 用状态机机制实现对事务 (Transaction) 的可靠传输。
2.根据权利要求 1 所述的利用状态机机制实现事务可靠传输的 方法， 其特征在于： 所述的请求队列中， 事务的状态包括：
状态 a: 请求事务第一次被发送给对端实体；
状态 b: 发送给对端实体的请求事务在定时时间内没有收到响 应， 该请求事务被重发一次或多次；
状态 c: 在向对端实体发送渚求事务后接收到对端实体对该请 求事务的临时响应 ( Transaction Pending )。
3.根据权利要求 2 所述的利用状态机机制实现事务可靠传输的 方法，其特征在于：所述的触发请求队列中事务状态变化的事件包括: 事件 a: 从对端实体接收到对请求事务的响应；
事件 b: 从对端实体接收到对请求事务的临时响应；
事件 c: 请求事务的重传定时器超时；
事件 d: 请求事务达到了最大重传次数。
4.根据权利要求 3 所述的利用状态机机制实现事务可靠传输的 方法， 其特征在于： 所述的请求队列中， 事务的状态与事件的操作变 化为：
当接收到事件 a, 当前状态为状态 a时： 将事务从请求队列中丟弃； 当接收到事件 a, 当前状态为状态 b时： 将事务从请求队列中丢弃； 当接收到事件 a , 当前状态为状态 c时： 将事务从请求队列中丢 弃， 向对端实体发送一个确认消息；
当接收到事件 b , 当前状态为状态 a时： 将事务的重传定时器的 值设置为临时响应定时器取值， 重传次数置零， 事务的状态迁至状态 c; 当接收到事件 b , 当前状态为状态 b时： 将事务的重传定时器的 值设置为临时响应定时器取值， 重传次数置零， 事务的状态迁至状态 c; 当接收到事件 b， 当前状态为状态 c时： 不操作；
当接收到事件 c , 当前状态为状态 a时： 重新发送一次该事务， 重传次数增加， 事务的状态迁至状态 b;
当接收到事件 c , 当前状态为状态 b时： 重新发送一次该事务， 重传次数增加；
当接收到事件 c , 当前状态为状态 c时： 重新发送一次该事务， 重传次数增加， 将事务的重传定时器重新设置， 事务的状态迁至状态 b; 当接收到事件 d, 当前状态不会为状态 a;
当接收到事件 d， 当前状态为状态 b时： 采取替代服务或拆除现 有连接或即将建立的连接；
当接收到事件 d , 当前状态不会为状态 c。
5.根据权利要求 1、 2、 3或 4所述的利用状态机机制实现事务可 靠传输的方法， 其特征在于： 所述的应答队列中， 事务的状态包括： 状态 A: 第一次接收到对端实体的请求聿务；
状态 B: 对接收到的请求事务的响应已发送给对端实体； 状态 C : 接收到对端实体对应答事务的确认响应 （Response Acknowledgement )。
6.根据权利要求 5 所述的利用状态机机制实现事务可靠传输的 方法，其特征在于：所述的触发应答队列中事务状态变化的事件包括： 事件 A: 从对端实体接收到请求事务；
事件 B: 从对端实体接收到对应答事务的确认响应；
事件 C: 向对端实体发送响应的事务号 （Transact ion ID )保存 时间超时。
7.根据权利要求 6 所述的利用状态机机制实现事务可靠传输的 方法， 其特征在于： 所述的应答队列中， 事务的状态与事件的操作变 化为：
当接收到事件 A， 当前状态为状态 A时： 发送一个临时响应给对 端实体， 不执行该请求事务， 临时响应重发达到一定次数后将应答事 务从应答队列中删除；
当接收到事件 A， 当前状态为状态 B时： 重新发送一次应答事务 给对端实体， 不执行该请求事务；
当接收到事件 A, 当前状态为状态 C时： 不执行该请求事务； 当接收到事件 B, 当前状态为状态 A时： 不操作； 当接收到事件 B, 当前状态为状态 B时： 将应答事务从应答队列 中删除， 仅保存事务号， 事务的状态迁至状态 C;
当接收到事件 B, 当前状态为状态 C时： 不操作；
当接收到事件 C， 当前状态不会为状态 A;
当接收到事件 C, 当前状态为状态 B时： 将应答事务从应答队列 中删除， 丢弃相应的事务号；
当接收到事件 C, 当前状态为状态 C时： 丟弃相应的事务号。
PCT/CN2003/000788 2002-11-11 2003-09-17 Procede de realisation d'une transmission fiable d'un mecanisme de transaction d'un automate fini WO2004045146A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU2003271019A AU2003271019A1 (en) 2002-11-11 2003-09-17 A method for realize the reliable transmission of transaction mechanism of state machine

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CNB021483671A CN100417154C (zh) 2002-11-11 2002-11-11 一种利用状态机机制实现事务可靠传输的方法
CN02148367.1 2002-11-11

Publications (1)

Publication Number Publication Date
WO2004045146A1 true WO2004045146A1 (fr) 2004-05-27

Family

ID=32304066

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2003/000788 WO2004045146A1 (fr) 2002-11-11 2003-09-17 Procede de realisation d'une transmission fiable d'un mecanisme de transaction d'un automate fini

Country Status (3)

Country Link
CN (1) CN100417154C (zh)
AU (1) AU2003271019A1 (zh)
WO (1) WO2004045146A1 (zh)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7349384B2 (en) * 2004-12-10 2008-03-25 Microsoft Corporation Reliable one-way messaging over request-response transport protocols
CN1855931B (zh) 2005-04-20 2010-08-04 华为技术有限公司 下一代网络中媒体网关上报事件处理方法
CN100347993C (zh) * 2005-09-27 2007-11-07 清华大学 基于通讯多端口有限状态机的协议互操作性测试生成方法
CN101286862B (zh) * 2007-04-09 2012-07-04 中兴通讯股份有限公司 接入设备中组播业务主备同步和倒换的方法
CN101179465B (zh) * 2007-12-10 2010-12-15 中国科学院计算技术研究所 一种无线网络媒体接入控制系统及其服务流动态处理方法
CN101206687B (zh) * 2007-12-18 2011-04-06 同济大学 一种提高分布式机电装备的动态安全性的方法
CN101447857B (zh) * 2008-05-26 2012-07-18 中兴通讯股份有限公司 一种消息处理过程中动态调整时间参数的方法
CN103729259B (zh) * 2012-10-12 2017-02-01 安凯(广州)微电子技术有限公司 一种AHB总线读写burst相互打断的验证方法及装置
CN106250250A (zh) * 2016-08-09 2016-12-21 广州唯品会信息科技有限公司 数据通信方法及装置

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0820016A2 (en) * 1996-07-01 1998-01-21 Sun Microsystems, Inc. A multiprocessing system including an enhanced blocking mechanism for read-to-share-transactions in a NUMA mode
US5878235A (en) * 1996-10-03 1999-03-02 Micron Electronics, Inc. Method and system for concurrent computer transaction processing
WO2001011524A1 (en) * 1999-08-04 2001-02-15 Rapidmoney Corporation System and method for rapidly and securely transferring funds electronically between two points
US6405292B1 (en) * 2000-01-04 2002-06-11 International Business Machines Corp. Split pending buffer with concurrent access of requests and responses to fully associative and indexed components

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0820016A2 (en) * 1996-07-01 1998-01-21 Sun Microsystems, Inc. A multiprocessing system including an enhanced blocking mechanism for read-to-share-transactions in a NUMA mode
US5878235A (en) * 1996-10-03 1999-03-02 Micron Electronics, Inc. Method and system for concurrent computer transaction processing
WO2001011524A1 (en) * 1999-08-04 2001-02-15 Rapidmoney Corporation System and method for rapidly and securely transferring funds electronically between two points
US6405292B1 (en) * 2000-01-04 2002-06-11 International Business Machines Corp. Split pending buffer with concurrent access of requests and responses to fully associative and indexed components

Also Published As

Publication number Publication date
CN100417154C (zh) 2008-09-03
AU2003271019A1 (en) 2004-06-03
CN1499802A (zh) 2004-05-26

Similar Documents

Publication Publication Date Title
CN107204834B (zh) 一种基于udt协议的高速网络可靠传输的控制方法
TWI483589B (zh) 資料傳輸及重新傳輸之方法
JP4414236B2 (ja) 通信システムにおいてデータの流れを制御する方法および装置
US7031273B2 (en) Session initiation protocol retransmission method
WO2010069206A1 (zh) 无线链路控制层报文状态报告的发送方法及系统
TW200926721A (en) Method and apparatus for enhancing various PDCP and layer 2 operations
JP4601871B2 (ja) 通信システムにおけるデータ流れの制御方法
JP2013146068A (ja) 通信セッション管理におけるトランザクションタイムアウト処理
WO2008041329A1 (en) Data transfer method
WO2013177841A1 (zh) Ac与ap之间链路保活的检测方法及装置
WO2011100911A2 (zh) 探测处理方法、数据发送端、数据接收端以及通信系统
WO2004045146A1 (fr) Procede de realisation d'une transmission fiable d'un mecanisme de transaction d'un automate fini
WO2009127112A1 (zh) 一种流控制传输协议状态迁移的方法
US20030158959A1 (en) Establishment of communications using point to point protocols such that duplicate negotiations are avoided
US20100115102A1 (en) Method for improving a tcp data transmission in case the physical transmission medium is disconnected
WO2007071133A1 (fr) Procede de mise en oeuvre d'une fonction de commande de processus de protocole iuup/nbup
US9794109B2 (en) Method of maintaining network address translation mapping and client device employing same
CN116112128B (zh) 发送重传请求的方法及装置、数据接收端设备和存储介质
CN101809970A (zh) 无线链路控制实体的复位方法
WO2007124634A1 (fr) Procédé de retransmission de données dans le protocole de commande de liaison radio
JP4384676B2 (ja) データ通信装置の制御方法
WO2010130156A1 (zh) 在双向数据传输中发送ack响应的方法、设备和系统
JP4364763B2 (ja) データ通信装置
WO2007014525A1 (fr) Procede d'etablissement d'une liaison entre le dispositif reseau et le terminal de reseau
WO2023155690A1 (zh) 数据传输方法以及装置

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP