KR100285177B1 - Reliable Multiparty Information Transmission Method in Internet Protocol Multicasting Environment - Google Patents

Abstract

1. TECHNICAL FIELD OF THE INVENTION

The present invention relates to a reliable multi-party information transmission method.

2. The technical problem to be solved by the invention

An object of the present invention is to provide a multi-party information transmission method that enhances reliability of information transmission by using Internet protocol (IP) multicast, which is essential for multi-party video conferencing, which is difficult to use transmission control protocol (TCP).

3. Summary of Solution to Invention

The present invention includes a first step of classifying a packet of a multiparty session application; A second step of performing a single packet reliable transmission since there is a lot of control data that emphasizes sudden and fast response time in case of small size data; And a third step of performing multi-packet reliable transmission to reduce network traffic rather than response time with large size memory transmissions.

4. Important uses of the invention

The present invention is used for teleconference, distance education and the like.

Description

Reliable Multiparty Information Transmission Method in Internet Protocol Multicasting Environment

The present invention relates to a method for reliable multiparty information transmission in an Internet Protocol (IP) multicasting environment.

Conventionally, there is a problem that efficiency is lowered by ignoring the nature of each data and transmitting in the same manner.

In recent years, Internet technology has advanced rapidly. Representative examples of such Internet successes will not hesitate to list the World Wide Web and the Multicast Backbone (MBone). The domestic response to the multicast backbone (MBone) is still not as great as in the WWW. However, in order to meet the expectations of multilateral communication such as tele-learning, teleconference, internet broadcasting, and internet radio, we are currently researching multicast suitable for multilateral communication in Korea.

The most urgent problem in real time multimedia communication is the construction of an Internet Protocol (IP) multicast environment. Currently, since Internet protocol (IP) multicast is not common in Korea, repeating using a transmission control protocol (TCP) or a user datagram protocol (UDP) is mainly used for multi-party conferences. Repeating) structure is used. This structure rapidly takes up network bandwidth as more participants participate.

On the other hand, when using Internet Protocol (IP) multicast, the network occupancy increases linearly as the number of participants increases, and the network occupancy is similar to 1: 1 session when session control is performed at the upper level. However, there are still many problems to be solved in multicast. For example, if there is no mechanism to limit the bandwidth, and an arbitrary user deliberately abuses a high time-to-live (TTL) network packet, the global network bandwidth is wasted if there are hosts in the same multicast group worldwide. This can result in processing loads due to unnecessary packets on hosts that join the same multicast group. This is because there is no clear management of the multicast backbone (MBone). This can cause interference due to packets between unrelated sessions.

And, the most urgent problem in application production is that multicast only provides unreliable transmission. There is no reliable transport standard for multicast yet, and there is no commercially accepted and widely used software. Compared with 1: 1, N: M communication is difficult to manufacture due to the complicated processing process, and multicast is still in the development stage. Although much research is currently being conducted on reliable transmission of multicast, none of the software is easy to use at the application level and satisfies the programmer's requirements in producing each application. Such restrictions present significant obstacles when creating multiparticipant conferences. Due to the lack of a multicast reliable transport protocol, in the case of developing a teleconferencing with only multicast, important control packets are lost and the subject of the conference is out of the intended direction. In addition, when using a common white board, packet loss may cause the screen output of each other to be inconsistent, thereby making it impossible to collaborate.

As a result, reliability must be handled at the application level. As the complexity of the application grows, there are too many things to consider in each application. After all, there should be a part dedicated to this, whether it be a library or a system service.

In the protocol of the present invention, it is configured as a lower network layer to provide reliability. However, a heavy network layer has a fatal effect on the overall execution time, so the lower network layer should occupy less processing time.

Accordingly, an object of the present invention is to provide a multi-party information transmission method that enhances reliability of information transmission by using Internet protocol (IP) multicast, which is essential for multi-party video conferencing or the like, in which transmission control protocol (TCP) is difficult to use.

1 is an exemplary configuration diagram of a system to which the present invention is applied.

2 is a hierarchical separation of a protocol according to the present invention.

3 is an exemplary view of a data structure in accordance with the present invention.

4 is an exemplary format of a network packet according to the present invention.

5 is a flow diagram of an embodiment of a method for reliable multi-party transmission of a single packet in accordance with the present invention.

6 is a flowchart illustrating an exemplary method for reliable multi-party transmission of multiple packets according to the present invention.

* Explanation of symbols for the main parts of the drawings

11: multicast group distribution center 12: GMCSC server

13: GMCSC Daemon 14: GMCSC Repeater

15: Application 16: GMCSC using a repeater

In order to achieve the above object, the present invention provides a multi-party information transmission method applied to an Internet Protocol (IP) multicasting apparatus, comprising: a first step of classifying a packet of a multi-party session application; A second step of performing a single packet reliable transmission since there is a lot of control data that emphasizes sudden and fast response time in case of small size data; And a third step of performing multi-packet reliable transmission in order to reduce network traffic rather than response time with large size memory transmission.

The above objects, features and advantages will become more apparent from the following detailed description taken in conjunction with the accompanying drawings. Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings.

First, comparing the reliable multipoint transport layer (RMTL) and 1: 1 transmission is shown in Table 1 below.

Item 1: 1 transmission RMTL (SPT) RMTL (MPT) Total packets N * H + N * H = 2 (N * H) N + N * H = N (1 + H) N + 1 + H Time required to send a packet (N * H-1) * T (N-1) * T + R (N) T + R

In Table 1, N denotes the number of transmission packets, T denotes a single packet transmission interval, H denotes the total number of recipient hosts, and R denotes the maximum value of an arbitrary waiting time when sending an acknowledgment packet.

First, the time required for the packet transmission of 1: 1 transmission, the sender receives the ACK packet immediately after sending the packet to the first host. This is the time when this process is performed sequentially for each packet. Here, R time is not necessary. It is assumed that packet transmission to another host is possible while receiving an acknowledgment (ACK). Therefore, a time of (total number of packets minus 1) * T is required.

In addition, looking at the time required for packet transmission of the RMTL (SPT), (N-1) * T time is required to multicast each packet. The acknowledgment packet is received during transmission, and only the last acknowledgment packet arrives in R time. Therefore, the total time needs (N-1) * T + R time.

Next, look at the time required to send a packet of RMTL (MPT), the (N + 1-1) time is required, because the number of (packet + 1) data packets are sent and the last response request packet is sent, each receiver It takes R time to get a response from. Therefore, a time of N * T + R is needed.

Looking at this intuitively by assigning an arbitrary value to the numerical value, it is as shown in Table 2 below.

Item 1: 1 transmission RMTL (SPT) RMTL (MPT) Total packets 2 (N * H) = 6000 N (1 + H) = 3100 N + 1 + H = 131 Time required to send a packet (N * H-1) * T = 59980 ms = 59.98sec (N-1) * T + R = 2000ms = 2 sec (N) T + R = 2020 ms = 2.02sec

Here, N is 100 packets, T is 20 ms, H is 30 hosts, and R is 20 ms.

In Table 2, the multi-packet transmission of the RMTL has a significant advantage in terms of the total number of packets and the transmission time. This advantage is used for large data transmission such as large file transfer, video transmission, and the like, and shows great efficiency.

1 is an exemplary configuration diagram of a system to which the present invention is applied.

The Multicast Group Distribute Center (MGDC) 11 manages a group of multicasts for independent session management between multicast groups. The administrator or program of a server that wants to use each Internet Protocol (IP) multicast group is assigned to the Internet Protocol (IP) multicast group by mail or program.

The Global Multicast Conference Session Control (GMCSC) Server (12) is a server mainly responsible for Port Management, and is an Internet Protocol (IP) multicast assigned by the Multicast Group Distribution Center (MGDC) 11. Assign ports from the group.

The GMCSC daemon (13) receives an invitation message from the host, receives a network event such as a letter, and activates an application.

And, each application 15 is activated as one daemon (Daemon), respectively.

The GMCSC repeater 14 receives and retransmits a packet like a mixer or a translator.

2 is a hierarchical separation of a protocol according to the present invention.

Global Multicast Conference Session Control (GMCSC) is a global session control (Multicast) protocol using multicast, which enables overall session management by using Transmission Control Protocol (TCP) or Internet Protocol (IP) multicast and this algorithm, RMTL. to provide.

Local Conference Session Control (LMCSC) is a session management protocol that has different characteristics from long-distance session control using multicast.

Multicast Conference Data Transfer (MCDT) is a protocol for efficient data transmission. It features multipoint simultaneous transmission and reliable transmission.

All these protocols are designed to eventually run on RMTL.

3 is an example of a data structure according to the present invention.

First, the main functions of each class hierarchy are as follows.

CksStaticHostGroup: Variable array indicating the reception status of hosts. Each destination host can have the following five values.

SHG_STATE_None: Initial state

SHG_STATE_Host_Received: Host that received the packet

SHG_STATE_Host_NoAnswer: Hosts with no response (ACK or NAK) for a certain period of time. The actual implementation acts like SHG_STATE_Host_Droped.

SHG_STATE_Host_Denying Hosts that refuse to receive the packet for any reason.

SHG_STATE_Host_Droped: This value is obtained when a host drop is notified from the higher session protocol. After a while, the host is deleted from the host list.

-CksStaticPacketGroup: In case of multi packet transmission, this class maintains a list of hosts that lost the packet for each packet. When the sender receives a lost packet list with non-response (NAK) from the receiver, it stores it in the CksStaticPacketGroup class. This is used on the next transmission to retransmit the packet only to lost hosts.

CksDataManager contains routines for storing and processing packet data. It is a data structure that can be used for both single packet data and multiple packet data, and has a function for convenient use in packet division.

-CKsSendQItemRoot: When classifying trusted transmissions, the common elements of the properties of each mode were extracted to be the class root of the item of the transmission queue.

CksQItemSPkt: A class that can be an item of a transmission queue. An item of a queue for transmitting a single packet. It inherits from CKsSendQItemRoot to qualify as an item in the send queue, inherits CksStaticHostGroup, and holds the host's state list. Inherits CKsDataManager and holds a copy of the transmitted data.

CksQItemMPkt: A class that can be an item of a transmission queue, and is a multiple packet transmission queue item. It inherits all the parent classes of CksQItemSPkt and manages the packet loss host list for each sub packet when inheriting CksStaticPacketGroup and dividing the transmission data by segment. The packet loss host list of each subpacket is reinitialized after completing the retransmission process.

CksRMTLSendQ: This is a transmission queue for reliable transmission of RMTL. In a totally-ordered transmission structure, the next item cannot be transmitted until one item is transmitted.

CksMPReceivingInfo: Receive buffer used for reception in multiple packet transmission. When the first packet is received among the subpackets, memory is allocated as much as the total data size, and then the subpacket is received and copied into the allocated memory. When all subpackets are received to form a data block, the reception process is completed and the completed data block is sent to a higher layer.

-CksReceivingItem: Inherits CksMPReceivingInfo and additionally has main sequence number and status information for each host to handle receiving. When receiving a packet, it is possible to first determine whether the received packet is a received packet, a current combination, or a packet requiring a new combination through the main sequence number comparison process and status information by referring to the CksReceivingItem of the corresponding host. This class acts as an item in the hash table for the host in CdynHostGroupLocal. Since RMTL is a fully symmetrical structure, one host must monitor the transmission status of all other hosts. The hash table of CydnHostGroupLocal does this.

CksDynHostGroupGlobal: Host group manager used in the session control layer, which is the upper layer of RMTL, to manage the entire host list of the session. When an application manages one CksDynHostGroupGlobal class and receives a Host Drop message from one instance among several CksDynHostGroupLocal, CksDynHostGroupGlobal notifies each CksDynHostGroupLocal. This reduces the processing overhead of dropping hosts from other CksDynHostGroupLocal.

CksDynHostGroupLocal manages the host group of each channel in multiple communication channels during a session. Exchange host state information with other CksDynHostGroupLocal through CksDynHostGroupGlobal.

As discussed above, CKsRMTLSendQ is a transmission Q used for reliable transmission of data. Data is divided into single packet data (CKsQItemSPkt) and multiple packet data (CksQItemMPkt), and are separated into classes according to what is done here. CKsDynHostGroupGlobal is a data structure used to specify a destination by maintaining a list of participants who join and leave a session. Here, the list of participants at the time of the transmission request is copied to the CKsStaticHostGroup to receive a response from them and decide whether to receive it. CKsStaticPacketGroup is a data structure used when one or more packets are sent and combined to form a data block.

4 is an exemplary format of a network packet according to the present invention.

CPktRoot is the root of all packets. It provides basic functions such as distinguishing from other packets and types of subpackets. CPktRMTLRoot is actually a packet used to implement RMTL. In RMTL, this packet type and subclass type provide multi-party reliable transmission and large data reliable transmission. Packets other than CPktMRTPSession can be defined at the same level as RMTL. Subclasses of RMTL are all subpacket headers for implementing RMTL.

5 is a flowchart illustrating an exemplary method for reliable multi-party transmission of a single packet according to the present invention.

For single packet reliable transmission, the following simple algorithm is used. In the case of small data, the algorithm considers a lot of control data that emphasizes sudden and fast response time.

The sender side first transmits the data packet to the destination host group (having a 32-bit Internet protocol address list in the packet) (51).

After receiving the data packet, the receiver side compares the main sequence number in the received packet with the main sequence number of the CKsDynHostGroupLocal and if it has already received and processed the data block, does not pass it to the upper layer. After processing (52), an ACK packet is transmitted by unicast (53).

Next, the sender receives a positive ACK packet and sets the host as SHG_STATE_Host_Received in the CKsStaticHostGroup. If all hosts of the CKsStaticHostGroup are not in the SHG_STATE_None state, successful transmission ends, so the next data block is prepared for transmission. If the processing of all the hosts is not finished, after [t, t, 2t, 4t, 8t 16t] seconds (54), retransmission starts from the first process (51). However, t is a time interval determined according to the network bandwidth, and t basically has 100 ms (Milli-Second) and is increased or decreased in consideration of a transmission / reception state during transmission.

And, even after the last retransmission, the sender side considers the host in SHG_STATE_None (the host with no response) to be a dropout host and notifies the CKsDynHostGroupLocal class so that data will not be delivered to this host from the next transmission of the corresponding channel. It also notifies the CKsDynHostGroupGlobal class so that it can also notify other channels in the same application.

6 is a flowchart illustrating an exemplary method for reliable multi-party transmission of multiple packets according to the present invention.

In the case of multiple packet transmission, unlike single packet transmission, non-response (NAK) is mainly used. This is because there is a significant network load when transmitting an acknowledgment (ACK) every subpacket. The algorithm used for multiple packet transmission is as follows. In the case of multi-packet transmission, it is designed to reduce network traffic rather than response time with large memory transfer.

First, the sender transmits 61 data packets as many as the number of subpackets segmented in one main sequence number to the destination host group.

Then, after the receiver receives the subpacket of the corresponding main sequence number, the main sequence number in the received packet is compared with the main sequence number of the CKsDynHostGroupLocal, and if the data block has already been received and processed, the process ends immediately. If the packet has not been received, the combination process is performed. ACK / NAK packets are not sent now.

Looking at the combination process in detail, if the packet is first received by comparing the main sequence number, the memory is allocated as much as the Total Data Size field of the packet. If the memory allocation fails, a receive denying packet is transmitted, and the main sequential number is increased to immediately transmit an ACK packet and terminate processing when receiving the next packet (63). If the memory allocation is successful, copy the packet data to the allocated memory of CKsDynHostGroupLocal.

If the packet is not the first packet received in the corresponding main sequence number, the sub packet continues to be copied to the allocated memory, and then the packet is set to the "Received" state in the packet combination state array of CKsReceivingItem (62).

Thereafter, after the sender side has transmitted all the subpackets, it transmits an ACK request packet (64).

Subsequently, when the receiving host receiving the ACK request packet of the receiver side obtains a lost packet group from CKsStaticPacketGroup of CksDynHostGroupLocal and the number is 0 (when all the sub packets are received and the data is completed), the completed data is transferred to a higher layer. After the send process is completed, a positive response (ACK) is sent according to the main sequence number, and the CKsReceivingItem increases the host's main sequence number by 1 to prevent reprocessing of the data block. If the number of lost packet groups is not zero (when a lost packet is present), an acknowledgment (ACK) request packet is received, and a loss packet list is transmitted to a sender in a non-response (NACK) packet (65).

Next, when the sender side receives the acknowledgment packet, the sender sets the state to CKsStaticHostGroup as SHG_STATE_Host_Received. If all are set to a non-zero value, the multi-packet transmission ends successfully. If the NACK packet is received, the host is added to the CKsStaticPacketGroup (66). If the reception processing of all receivers is not finished, retransmission starts from the first process again after [t, t, 2t, 4t, 8t 16t] seconds (67). However, t is a time interval determined according to the network bandwidth, and t basically has 100 ms, and is increased or decreased in consideration of the transmission / reception status during transmission. (Retransmit the corresponding packet to the corresponding sub packet loss host group as the destination for each sub packet. Initialize the host group of the CKsStaticPacketGroup after sending the last lost packet.

Thereafter, after the last retransmission, the sender side considers the host in SHG_STATE_None to be a dropped host and notifies the CKsDynHostGroupLocal and CKsDynHostGroupGlobal classes so that the packet will not be delivered to this host from the next transmission.

The present invention described above is not limited to the above-described embodiments and the accompanying drawings, and various substitutions, modifications, and changes can be made in the art without departing from the technical spirit of the present invention. It will be apparent to those of ordinary knowledge.

The present invention as described above, by using the Internet Protocol (IP) multicast, which is essential for multi-party video conferencing, which is difficult to use the transmission control protocol (TCP), to enhance the reliability of information transmission to prevent malfunction of the program, to create a robust program It can be effective.

Claims (6)

In the multi-party information transmission method applied to the Internet Protocol (IP) multicasting device, Classifying packets of a multiparty session application; A second step of performing a single packet reliable transmission since there is a lot of control data that emphasizes sudden and fast response time in case of small size data; And Third step of performing multi-packet reliable transmission in order to reduce network traffic rather than response time in case of large data transmission Multi-party information transmission method comprising a. The method of claim 1, The second step, A fourth step in which the sender sends the data packet to a destination host group; After the receiver receives the data packet, it compares the main sequence number and passes it to the upper layer if the data block has already been received and processed. Transmitting a unicast message; And If the sender side receives a positive ACK packet, the state is changed to receive in the destination host list, and if all the hosts are non-none, the operation is terminated successfully, and if either host is non-one. Sixth Step of Performing Retransmission of Host to State Multi-party information transmission method comprising a. The method of claim 2, Even after the last retransmission, the sender side regards the host in the initial state (SHG_STATE_None) as a host that is not responding so that data is not transmitted to this host from the next transmission of the corresponding channel, and other channels in the same application 7th step to inform you of this fact The multi-party information transmission method further comprises. The method according to any one of claims 1 to 3, The third step, An eighth step of sending by the sender side to the destination host group as many data packets as the number of subpackets segmented in one main sequence number; A ninth step of receiving a subpacket of the corresponding main sequence number by comparing with the main sequence number, immediately ending the processing if the data block has already been received and processed, and performing a combining process if the packet has not been received yet; ; A tenth step of transmitting a response (AOK) request packet after the sender transmits all sub packets; ) The receiving host receiving the AOK request packet from the receiver receives the lost packet group, receives all the subpackets, sends the completed data to the upper layer when the data is on, and finishes processing the main sequence number. Sends a positive response (AOK) accordingly, prevents reprocessing of the data block by increasing the host's primary sequence number, receives a response (AOK) request packet if there is a missing packet, and then sends a non-response (NACK) packet. An eleventh step of carrying a lost packet list to the sender; And When the sender side receives the AOK packet, the receiver sets the reception state and successfully terminates the multi-packet transmission when all are set to the reception state. When the sender side receives the NACK packet, the sender sends the host to the lost packet list. 12th step to add Multi-party information transmission method comprising a. The method of claim 4, wherein Even after the last retransmission, the sender side regards the host in the initial state (SHG_STATE_None) as a host that is not responding so that data is not delivered to this host from the next transmission of the corresponding channel, and other channels in the same application are not transmitted. 13th step to inform you of this fact The multi-party information transmission method further comprises The method of claim 4, wherein The combination process of the ninth step, If the packet is first received by comparing the primary sequential number, the memory is allocated as much as the Total Data Size field of the packet, but if the memory allocation fails, the receive denying packet is transmitted and the primary sequential number is increased. When the next packet is received, it transmits an AOK packet and terminates the processing. If the memory allocation is successful, the packet data is copied to the allocated memory. And copying the subpacket into the allocated memory, and then setting the packet to a reception state in a packet combination state array.