KR100223014B1 - Error control method in multiparty communication - Google Patents

Abstract

The present invention relates to an error control method of a multimedia computer communication transmission protocol. When a heartbeat is sent to a source in a manner of notifying that a receiver has received the end of a message, the source uses the same to create a state table of all group members. Therefore, an error control method in a multi-party communication that enables reliable multi-media data transmission and minimizes data loss in a communication protocol of a computer communication is proposed.

Description

Error control method in multiparty communication

The present invention relates to an error control method of a multimedia computer communication transmission protocol, and more particularly, to a reliable error control method in multiparty communication.

The recent trend toward the globalization of the world is bringing close contact between many regions within a country and countries around the world through communication and information processing. These requirements are not simply solved through traditional mail, phone, or fax. Instead, face-to-face and face-to-face conversations can be achieved through application services such as remote collaboration, remote lecture, telemedicine, and teleconference. Various multimedia application services such as groupware supporting group collaboration are required.

One approach to jointly dividing and using application services seeking to speed up and diversify is to develop transport protocols for multiple users.

However, in most cases, the 1: 1 transport protocol method used to share a single-user that supports only the interaction between the existing user and the system.

As part of efforts to solve this problem, the recent communication network and application service fields have highlighted the necessity of transport protocol as an important research area, and the high speed transport protocol is emerging as a new research field for multimedia application in heterogeneous high speed networks. The Open System Interconnection (OSI) Transport Protocol (TP) 4 stack, or the Transmission Control Protocol (TCP) / Internet Protocol (IP), is used to transfer common text data. As a protocol, it is not suitable to provide real-time communication required in a multimedia environment and communication to reliably process a large amount of data. In addition, due to the increase of various computer communication networks, the increase of transmission speed according to the development of communication technology and transmission device, the development of computer technology, and the expansion of new application service area including various multimedia, the requirements accompanying this can be satisfied. It was not suitable as a communication protocol, and since they were developed at a time when network bandwidth was narrow, error occurrence rate was high, and system resources were insufficient, the main goal was to efficiently use bandwidth and detect and recover errors. However, the current high speed network environment is a new structure structured for the current high speed network environment and the method of changing or extending the function of the existing protocol, minimizing the protocol processing time, and solving the performance degradation caused by the structural problem of the existing protocol. Methods of designing protocols are being mobilized. Since the extension of the existing protocol is not a long-term solution, the study of the new protocol design has been actively studied recently.

Error control is intended to reliably provide data transmission for multimedia applications such as cooperative work in the multi-party transmission protocol environment of multimedia computer communication. Existing error control methods have been used mainly for document-oriented text data when the network conditions such as jitter and delay are unstable and the performance of speed is poor. Therefore, the high speed based on the current high speed transmission network Many shortcomings have emerged for use as the error control method required in the information communication environment.

In the end-to-end communication where an existing sender and a receiver establish a 1: 1 connection to exchange data with each other, the receiver receives the sender's data in a reliable manner. And responding to the sender the status of the received data. Error control is a function to find and solve errors that occur during data transmission between these transceivers. Errors that can occur during transmission and reception include modification of transmitted packet contents, order and change of packet arrival, arrival of duplicate packets, and packet loss. The error control function has three functions such as error detection, error reporting, and error recovery (correction).

end. Error detection function

This function checks whether packets arrive in the order in which they are sent without modification of the contents. In order to detect an error, a message is received using information such as sequence number, packet length, and data checksum, inspected, and followed by the next message.

I. Error report function

Error reporting is a function that delivers information about the arrival of a wrong packet or a lost packet to the sender. Instead of acknowledgment (ACK), the packet is selected only when the packet arrives. Negative acknowledgment (NACK) is well known, and in general, the existing protocol does not have such an error reporting function and positive acknowledgment that the receiver reliably responds to the sender within a certain period of time. In the case of many-to-many communication, data transmission is a cause of overload because errors are frequently detected due to the arrival of packets.

All. Error recovery function

Error recovery (correction) is a function to recover the reported error through retransmission. It uses the method of retransmitting all packets after the error packet, and it is easy to apply to the communication network with high error rate because it is simple to implement. Although it is adopted and used in protocols, there is a need for a modified method in a high speed network environment where current reliability is improved and a large amount of data is transmitted in a short time.

The above functions are simply error-prone method that occurs in end-to-end communication consisting of one sender and one receiver, and many-to-many like a multimedia environment. In multi-point, multi-party communication, it is not suitable for solving errors that occur simultaneously between one or several senders and many receivers.

Accordingly, an object of the present invention is to satisfy the requirements for various multimedia application services in a multi-point, multi-party communication environment by improving the reliable transmission and reception of data using error control methods suitable for a multimedia computer communication environment.

In order to achieve the above object, the present invention provides a method of transmitting a heartbeat message in a multicast form from a source to a receiver for continuous information retention of a receiver, and receiving a final message from a receiver receiving a heartbeat message from the source. In this case, the method comprises the steps of transmitting a heartbeat message to the source by unicast, and creating a state table at the source receiving the heartbeat message from the receiver.

1 is a state diagram for error detection and retransmission request in accordance with the present invention.

2 is a state processing diagram for error correction according to the present invention.

* Explanation of symbols for main parts of the drawings

11: Received State 12: Standby 2 State

13: Standby 3 state 21: Transmission state

22: Receive state 23: Standby 1 state

24: Transmission recovery status 25: Heartbeat status

In the multimedia computer communication, as a method of error control for reliable message delivery between multi-point and multi-party, the conventional method of 1: 1 for reliable message delivery uses a simple method of retransmitting all parts from an error occurrence. In a many-to-many environment, if each error occurs, the solution is to calculate the time taken for round-trip communication with the receiver with the worst or farthest network conditions when establishing a connection. While listening to the NACK of the receiver reporting that an error has occurred, if there is a receiver that sent the NACK earlier than itself, the receiver recognizes that an error has occurred and retransmits the message from the source.

In the conventional method, the heartbeat sending method for checking the interoperation state by the connectionless structure between the source and the plurality of receivers requires a process of receiving an acknowledgment of the opposing operation state every time. The method incurs a lot of overhead if this is received by a large number of recipients. Therefore, if the source does not transmit data for a certain period of time, it sends a heartbeat message instead of the data to maintain an implicit connection between the source and the receiver. That is, the heartbeat message is a control message used to inform each other of its own state in order to ensure the reliability of data transmission when data transmission is stopped while the source and the receiver are transmitting and receiving data. Heartbeat messages include the time the heartbeat message was generated, the user data sequence number recipient identifier, and the port number. The user data sequence number is the sequence number of the last user data packet sent by the source, and the receiver identifier is the heartbeat message. Is the destination address where it should be received, and the port number is the identification number for identifying the connection.

Since the process for retransmission by the source and the surrogate host is transmitted and received only by the sender and the receiver in the conventional method such as 1: 1, the request of data retransmission of the receiver was of course the role of the sender, but many-to-many. In many environments, the sender has a lot of overhead to deal with the retransmission request of all receivers alone. To solve this problem, if the source cannot respond to the retransmissions of the receivers, a surrogate host is assigned to respond to the retransmission requests of the receivers.

A user who participates in communication consists of several sources (hereinafter referred to as sources) and a plurality of receivers (hereinafter referred to as receivers), and establishes a connection therebetween to transmit and receive data. During data transmission, an error occurs due to the loss of the transmission message (corruption or loss) and the sudden change of environment between the systems set between both terminals such as congestion and failure of network traffic and system down. need. In the present invention, these processes are classified into an error detection method and an error correction method as follows.

1. Error detection method

end. How to control message failure errors

This method only handles errors for messages sent between sources and recipients. The source and receiver use the message sequence number to recognize the data sent and received. The sequence number starts with a number and increases sequentially for each data packet for identification, and the sequence number keeps each source independent. The receiver detects the loss by finding the gap between the sequence numbers and detects the packet corruption by the checksum value of the data packet.

Heartbeat messages are used to indicate the presence and status of the source host. The originating heartbeat message is sent only by the source host and is included in the sequence number of the last packet. The heartbeat is generated as follows. Heartbeats occur when a source does not transmit data, and the purpose is to allow the receiver to recognize the source's loss of data, to indicate the source's downtime, source's activity, and so on. Perform is used when a source pauses for a period of time. If the source stops sending for a period of time, it will send heartbeats regularly until it is sent normally.

The recipient's heartbeat utilization means uses the receiver's heartbeat message as an indication to respond to any request for the sender's heartbeat transmission. Although the connection between the source and the receiver is still established without being disconnected, if for some reason the source inhibits data transmission, the amount of NACK, flow control parameters, Calculate constants such as the time it takes for round trip delivery.

Most participants in the conference will send small messages in small quantities, and in practice, they will occasionally transmit during the multicast session, limiting the heartbeat transmission time. These sources declare that they are no longer sources after sending five messages only for a certain time.

The receivers refer internally to the source reference state of the source, and if the receiver fails to get these messages and asks the source to improve its status, the source repeats the information again. After a certain period of time, the host transitions from source to receiver, whose data synchronization is the responsibility of the session and application layers, and the source no longer sends heartbeat messages.

The source keeps all the information about the receiver in the group, and the receiver keeps the status related information about the source.

The source sends a multicast heartbeat message to maintain information about the receiver, and the receiver also periodically sends a heartbeat message to the source to inform the receiver of the last message received.

The heartbeat information sent by the receiver can only be received by the source, not by other recipients, and the receiver sends the heartbeat to the source as unicast. This heartbeat contains the receiver identifier (ID) and the port number of the connection, as well as the sequence number of the last message received by the receiver.

The source uses a randomized method that periodically selects only one receiver to avoid heartbeat congestion from multiple receivers.

The source uses the heartbeats sent by the receiver to keep track of the receiver's status, and the source collects the receiver's status information with the heartbeats received by reducing the overhead by randomized methods from several other receivers. Make a list of group members in the state table. And all the recipients in the group use the first heartbeat message sent by the source to set up a status table for the source themselves.

Information about the state thus obtained is notified to higher layers. The source maintains state tables, which are the basis for ensuring reliability across communications, including subscription procedures, withdrawal procedures, flow control, and error control. The source notifies the application layer when the receiver stops talking. Once the source determines that the recipient has left, it removes the recipient from the recipient list and notifies the application layer of the change.

Here, the state table is managed by the source and the receiver. The state table on the source side is composed of a list of receivers that receive the packet transmitted by the source. Maintain correctly received packet sequence number. In addition, the status table on the receiver side is composed of lists of sources that transmit packets received by the receiver. Keep it.

The heartbeat of the source contains the source ID, the sequence number of the last message, and the port number. The receiver uses the sequence number of the first data packet to track the message sent by the source. The receiver sends a heartbeat message to the source at the unicast address to respond to the first message from the source. This heartbeat message is repeated periodically because there is no reliable ACK of the source other than the heartbeat. The source sends this heartbeat when there are no data packets to send and requests the receiver to send a response within the heartbeat period.

After receiving the first data from the source, the receiver's use of the heartbeat message is necessary to create a state table to provide reliability to the application layer and maintain receiver status.

In summary, the receiver heartbeats received by the source are randomly received at the source to avoid saturation of the heartbeats sent by the entire receiver.

The recipient's heartbeats are sent to the source in unicast, providing not only notification of the last message sent by the source, but also information that allows the source to manage group membership of all recipients. The sending of heartbeat messages to the receiver to the source is made by the source into a state table, which the source uses to keep track of the receiver's reception and progress, and is sent to all recipients in multicast. When all receivers have recognized that they have received the data, it deletes the data sent from its buffer.

1 is a state processing diagram for error detection and retransmission request according to the present invention.

In the Receiving 11 state, the receiver examines the checksum value of the packet to detect packet corruption, traces the packet sequence number to detect the lost packet, and once it knows that the data has been transmitted but not received. The receiver calls a timer. After the timer expires, the receiver goes to Wait2 (12) state. In this state, the receiver detects an error and sends a NACK to the multicast group. When the receiver waits in this state for damping to reduce the number of NACKs, other hosts in the multicast group listen to the NACKs. When the other host detects an error, the receiver moves to wait 3 (13) state, waits for a response of the error message, and returns to normal Receiving 11 state upon receiving corrected data. When the timer expires in wait 2 (wait_2) 12 state, the receiver generates an error message, sends it to the multicast group, and moves to wait 3 (Wait_3) 13 state. If there is no response from the other host (source or other receiver) to the error message, the receiver returns to wait 2 (12) state and generates the error message again. This back-and-forth transition between wait_2 12 and wait_3 13 only takes place five times. If no progress is made after the five timers have expired, the host assumes that an error has occurred in establishing a connection between the source and the receiver and notifies the application layer that an error has occurred.

I. Site failure error control method

This method is an error control method for the status of source and receiver. When the receiver stops receiving data, including the heartbeat message from the source, the receiver must send a specific message to the source to determine the source's status, sending the message directly to the multicast group or host. The advantage is that it uses a multicast tree so other hosts can continue to work.

If the source does not detect a retransmission request for a certain period of time, it needs to check whether it is disconnected with the receivers and there are no more listeners listening. Thus, the source sends a status request to the recipients. One of the recipients responds to the status request, and if the response is multicasted to all groups on the multicast address, the other receivers cancel their response. The source may know that once it receives the status request response, there is at least one recipient present to continue receiving data. If the source does not hear any response, it is assumed that the receiver's response is lost or that there are no recipients in the group.

To eliminate the possibility of losing a message, the source must repeat this status request several times before concluding that there are no recipients in the group.

When the source recovers from site failure of the site, the source will have a new sequence number and the receiver will have an old sequence number, requiring a brake. When the source sends a new start message with a new sequence number, the receiver receives the new start message and forces the brake. The source repeats the start three times in the data transfer so that the entire receiver receives the start. Recipients look at the header start message and inform the source with an NACK that an error has occurred if the start message is lost.

2. Error Correction Method

The transport protocol detects and corrects errors that occur during data transmission to ensure reliability. This ensures reliable data delivery to each participant, and each recipient is responsible for predicting his or her own loss of data.

The source determines that there is nothing wrong with the receiver's data reception if there is no NACK or heartbeat from the receiver. When the receiver is disconnected, even if the source has a retransmission method, no action can be taken to correct the error. As a countermeasure, the receiver must re-establish "connectivity" for the group and retransmit the data. Error detection is entirely the responsibility of the receiver, since the source only recognizes the lost data upon request of the receiver's lost data.

If the receiver finds and confirms one or more corrupted data in the message, it can request retransmission of the required data, which uses NACK.

The NACK is sent through an IP-Multicast group and other hosts see the request and use damping techniques to prevent transmission of the same request.

If the source cannot retransmit, have another host resend the data. Hosts capable of retransmission must have sufficient buffers for data to be able to perform retransmission processing.

The source has a large buffer that can meet the data retransmission requirements, and once the data is discarded, it is removed from the buffer. And since it is used as a buffer for new data, it can't be stored anymore. This structure is an example of a model used to efficiently use buffer management.

The use of damping techniques reduces the likelihood of message congestion caused by many recipients responding at the same time, in order to reduce congestion, the receiver immediately sends a NACK upon detection of lost data, and other recipients listen to the NACK. Other receivers do not need to send their own NACK if they detect a NACK (retransmission request). However, if no other NACK has been received, or if missing data replenishment is not sufficient, the local receiver needs to send a NACK by itself. Damping techniques are meaningless if all recipients wait for the same period. The time intervals that receivers wait for are usually different. Each receiver computes a random time value for listen before performing the retransmission request. The benefits of damping techniques reduce repetition and limit packet saturation at the source and network.

In the data transfer process, partial loss or damage of data occurs. The receiver requests retransmissions to them, either of which are resent by the source or peer-hosts. When the source has not sent data for some time, it sends a heartbeat message instead.

The two models for data retransmission are as follows.

end. How the source is responsible for resend:

Respond to all retransmissions of data. If for some reason the source cannot retransmit, the peer-hosts are responsible for the retransmission.

I. How all hosts are responsible for retransmissions:

Hosts are responsible for retransmission by listening to the source (including the source itself).

Excessive retransmission response has two solutions.

The first approach is done by the source itself, which is simple but the host is responsible for the retransmission request and the peer host does not respond. However, this method should be used selectively. For example, if the source host is overloaded with other things, retransmission delivery in time is not possible and should be used selectively.

The second method is performed by the source's agent, which slows down the retransmission process and delays the retransmission response of the peer-hosts when the source contains a connectivity problem. The advantage of having all hosts with potential retransmission points is that the source can be overloaded. This method can be efficient for other hosts (handles the response) that can respond quickly. Other hosts that are overloaded don't have a way. The retransmission performed by the host is when the source is more overloaded than the host.

The requirement for retransmission is satisfied even when using the source-priority model and when the retransmission capacity of the source is insufficient. If another host replaces the retransmission because of the overhead, the host must first be the receiver of the source data to perform this function, and the host can respond to the retransmission request in the same way as the source host. The source responds to the retransmission first because the source cannot avoid the response to the retransmission of the data. If the source is unable to respond to the retransmission request, the proxy host does it. In some cases, the surrogate host can resolve better than the source in handling retransmissions, and can decide enough time to respond to a surrogate retransmission request. This can be done using a specific number for the timer or retransmission request.

The way that the peer-hosts can prevent many request responses even after the peer-hosts retransmit the requested data can be solved by using a damping technique. All peer-hosts praying for a retransmission request response wait for a period of time listening to respond to a request from another host.

In special circumstances, if the source or receiver uses an out-of-procedure method, if the receiver does not receive a retransmission after five attempts and does not hear a heartbeat from the source during that period, the receiver determines that the source host is no longer available. That is, the source is considered to have already left the group. In either case, the receiver does not know the status of the source leaving the group, or the connection to the source is lost, either because there is no surrogate receiver that satisfies the retransmission request or the peer receiver does not have the desired data. In this case, the transport protocol notifies the application layer of an error occurrence. The application layer sees this and decides what to do next based on the context of the application layer. The recipient does not notice the withdrawal of the source. That is, the receiver is supposed to receive data or heartbeats regularly from the source.

If no message is received from the source for a certain amount of time, the receiver determines the status of the source. This is important because the receiver up-to-date the last listening from the source. At that time, it is unknown whether the source transmits other data.

The status of the source is obtained by the receiver through an explicit request. If the source is still in the multicast group but is the receiver, the previous source host indicates that it is no longer the source.

Past sources can no longer hold the last segment of data, and specify the sequence number of the last packet and send it to the source. The receiver then determines if there is any data lost. If the receiver notifies the application layer, the process by source transition is complete when the data at the source is no longer valid and the data is discarded from all recipients.

If the source is no longer a multicast group (on leaving), the status requester responds to the surrogate host, which determines that the surrogate hosts still have information about the source.

Recipients with data from the source and heartbeat messages will not be able to request re-transmission termination. This is due to a network error in which the path to the source returned to it. In this case, the surrogate receiver may perform retransmission from the source's point of view. If there is no surrogate receiver listening for the retransmission request, it terminates the error condition and notifies the application layer of this.

2 is a state processing diagram for error correction according to the present invention. As shown, a host in SENDING 21 or RECEIVING 22 state responds to an error request through another surrogate host. Upon receiving the error message, the host enters wait_1 (23) state to respond to the error message and provide correct correct data. The wait_1 (23) state is used for damping the surrogate host to respond to an error message. The host generates the modified data, starts the timer, and then sends the modified data to the multicast group after moving to the SEND_REPAIR 24 state at the end of the timer period waiting for another surrogate host to respond to the modified data. . However, if another surrogate host responds to the modified data, the host returns to the original SENDING 21 state or the RECEIVING 22 state.

Heartbeat messages are used to indicate the presence and status of the source host. The first heartbeat message is sent only by the source host and is included in the sequence number of the last packet. Heartbeats occur briefly during a meeting at the application layer or during an idle state where the source is not transmitting data.The purpose is to allow the recipient to recognize the intent that the source is not currently transmitting data, Indicate stop time, activity status, etc. If the source stops sending for a period of time, it will send heartbeats regularly until it is sent normally. If the source does not transmit data, after a certain period of time, the time required for round-trip delivery of the amount of NACK, flow control parameters, and constants is calculated.

The receiver also periodically sends a heartbeat message to the source to signal the last message (FINAL) received by the receiver. The heartbeat information sent by the receiver can only be requested by the source, not by other receivers, and the receiver sends the heartbeat to the source in unicast. This heartbeat contains the receiver ID and the port number of the connection, as well as the sequence number of the last message received by the receiver. The source uses a randomized method that periodically selects one receiver as a way to detect heartbeat congestion from multiple receivers.

As described above, according to the present invention, there is an effect of enabling reliable multi-media data transmission and minimizing data loss in a transmission protocol of computer communication.

Claims (2)

Sending a multicast heartbeat message from the source to the receiver to maintain the receiver's ongoing information; and sending a heartbeat message to the source in unicast upon receipt of the last message to the receiver receiving the heartbeat message from the source. And creating a state table at a source that has received a heartbeat message from the receiver. The method of claim 1, wherein the heartbeat message transmitted from the receiver to the source comprises a receiver identifier, a port number of a connection, and a sequence number of the last message received by the receiver.