KR100921491B1 - Message transmission method without loss in ring-type communication network - Google Patents

Message transmission method without loss in ring-type communication network Download PDF

Info

Publication number
KR100921491B1
KR100921491B1 KR1020050060880A KR20050060880A KR100921491B1 KR 100921491 B1 KR100921491 B1 KR 100921491B1 KR 1020050060880 A KR1020050060880 A KR 1020050060880A KR 20050060880 A KR20050060880 A KR 20050060880A KR 100921491 B1 KR100921491 B1 KR 100921491B1
Authority
KR
South Korea
Prior art keywords
message
token
daemon
received
transmission
Prior art date
Application number
KR1020050060880A
Other languages
Korean (ko)
Other versions
KR20070005844A (en
Inventor
배병구
Original Assignee
삼성탈레스 주식회사
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 삼성탈레스 주식회사 filed Critical 삼성탈레스 주식회사
Priority to KR1020050060880A priority Critical patent/KR100921491B1/en
Publication of KR20070005844A publication Critical patent/KR20070005844A/en
Application granted granted Critical
Publication of KR100921491B1 publication Critical patent/KR100921491B1/en

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/42—Loop networks
    • H04L12/427—Loop networks with decentralised control
    • H04L12/433—Loop networks with decentralised control with asynchronous transmission, e.g. token ring, register insertion
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1867—Arrangements specially adapted for the transmitter end
    • H04L1/1874—Buffer management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1863—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast comprising mechanisms for improved reliability, e.g. status reports
    • 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
    • H04L47/34—Flow control; Congestion control ensuring sequence integrity, e.g. using sequence numbers

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

본 발명은 토큰 링형 통신망 (토큰 ring network)에서 노드 간 메시지 전송 시 메시지의 무결성을 보장하기 위하여, 발생된 모든 메시지의 순서(ordering)를 보장하고 완전한 메시지의 전송을 보장하며, 멀티 케스팅을 통한 고 성능의 메시지 전송 서비스를 제공하기 위한 링형 통신망에서 손실없는 메시지 전송방법에 관한 것이다. 이를 위해, 본 발명은 a) 데몬이 토큰을 수신하면 토큰에 수신하지 못한 메시지의 전송요청이 있는지 확인하는 단계; b) 메시지의 전송요청이 있는 경우, 클라이언트수신버퍼를 확인하여 자신이 멀티캐스트할 메시지가 존재하는지 확인하는 단계; c) 멀티캐스트한 메시지를 시퀀스번호에 맞게 메시지 관리버퍼에 저장하는 단계; d) 메시지 관리버퍼를 검색하여 수신하지 못한 메시지가 존재하는지 확인하는 단계; e) 전체 시퀀스번호에 대한 정보를 토큰에 삽입하는 단계; 및 f) 다음 데몬으로 토큰을 전송하는 단계를 포함한다.The present invention ensures the ordering of all generated messages and ensures complete message transmission in order to ensure the integrity of messages when transmitting messages between nodes in a token ring network. The present invention relates to a lossless message transmission method in a ring-type communication network for providing a message transmission service of performance. To this end, the present invention comprises the steps of a) checking if the daemon receives a token, request for transmission of a message not received in the token; b) if there is a request to send a message, checking the client reception buffer to see if a message to be multicasted exists; c) storing the multicast message in the message management buffer according to the sequence number; d) searching for a message management buffer to check whether there is a message not received; e) inserting information about the entire sequence number into the token; And f) sending the token to the next daemon.

Description

링형 통신망에서 손실없는 메시지 전송방법{Message transmission method without loss in ring-type communication network}Message transmission method without loss in ring-type communication network

도 1은 본 발명의 링형 통신망에서 손실없는 메시지 전송방법이 적용되는 통신시스템망을 개략적으로 도시한 구성도이다.1 is a block diagram schematically illustrating a communication system network to which a lossless message transmission method is applied in a ring communication network of the present invention.

도 2는 본 발명의 메시지 관리버터의 동작 알고리즘을 설명하기 위한 개념도이다.2 is a conceptual diagram illustrating an operation algorithm of the message management butter of the present invention.

도 3은 본 발명에 의한 링형 통신망에서 손실없는 메시지 전송방법을 설명하기 위한 개념도이다.3 is a conceptual diagram illustrating a lossless message transmission method in a ring communication network according to the present invention.

도 4는 본 발명의 토큰 수신시 처리 알고리즘을 설명하기 위한 흐름도이다.4 is a flowchart illustrating a processing algorithm upon receiving a token of the present invention.

도 5는 본 발명의 멀티캐스트 수신시 처리 알고리즘을 설명하기 위한 흐름도이다.5 is a flowchart illustrating a processing algorithm upon multicast reception according to the present invention.

<도면의 주요 부분에 대한 부호의 설명><Explanation of symbols for the main parts of the drawings>

10...데몬정보관리 20...클라이언트정보관리10 ... Manage Daemon Information 20 ... Manage Client Information

30...메시지관리버퍼 40...클라이언트수신버퍼30 ... Message Management Buffer 40 ... Client Receive Buffer

50...클라이언트관리 50...메시지수신50 ... Client Management 50 ... Receive Message

70...메시지전송 80...토큰수신70 Send message 80 Receive token

90...토큰전송 95...클라이언트90.Token Transfer 95 ... Client

100, 200, 300, 400...데몬100, 200, 300, 400 ... daemon

본 발명은 토큰 링형 통신망 (토큰 ring network)에서 노드 간 메시지 전송 시 메시지의 무결성을 보장하기 위하여, 발생된 모든 메시지의 순서(ordering)를 보장하고 완전한 메시지의 전송을 보장하며, 멀티 케스팅을 통한 고 성능의 메시지 전송 서비스를 제공하기 위한 링형 통신망에서 손실없는 메시지 전송방법에 관한 것이다.The present invention ensures the ordering of all generated messages and ensures complete message transmission in order to ensure the integrity of messages when transmitting messages between nodes in a token ring network. The present invention relates to a lossless message transmission method in a ring-type communication network for providing a message transmission service of performance.

현재 대부분의 토큰 링형 통신망(토큰 ring network)에서 손실된 메시지의 재전송을 위하여 또 다른 토큰을 사용함으로써 시스템이 복잡해지며 또한 메시지 손실 발생 시 재전송 요청 및 응답을 위한 시간 소비가 많아 메시지 전송에 지연이 발생하며, 발생된 모든 메시지의 순서(ordering)를 완전하게 보장하지 않는 경우가 많다.In today's most token ring networks, the use of another token for retransmission of lost messages complicates the system and also causes delays in message transmission due to high time consumption for retransmission requests and responses in case of message loss. In many cases, the ordering of all generated messages is not completely guaranteed.

본 발명이 이루고자 하는 기술적 과제는 종래 기술의 문제점인 메시지 손실 발생 시 재전송 요청 및 응답을 위한 시간소비를 최소화하여 손실에 따른 메시지 전송지연을 감소시키며, 모든 메시지의 순서(ordering)를 완전하게 보장함으로써 메시지의 무결성을 보장하며, 멀티 케스팅을 통한 메시지 전송으로 메시지 손실없는 고 성능의 메시지 전송 서비스를 제공하는 것을 목적으로 하고 있다.The technical problem to be achieved by the present invention is to minimize the time spent for retransmission request and response when a message loss occurs, which is a problem of the prior art, to reduce the message transmission delay due to the loss, by ensuring the ordering of all messages completely It aims to guarantee the integrity of messages and to provide high performance message transmission services without message loss through message transmission through multicasting.

본 발명은 상술한 기술적 과제를 달성하기 위하여, 링형 통신망에서 메시지 전송방법에 있어서, a) 데몬이 토큰을 수신하면 토큰에 수신하지 못한 메시지의 전송요청이 있는지 확인하는 단계; b) 메시지의 전송요청이 있는 경우, 클라이언트수신버퍼를 확인하여 자신이 멀티캐스트할 메시지가 존재하는지 확인하는 단계; c) 멀티캐스트한 메시지를 시퀀스번호에 맞게 메시지 관리버퍼에 저장하는 단계; d) 메시지 관리버퍼를 검색하여 수신하지 못한 메시지가 존재하는지 확인하는 단계; e) 전체 시퀀스번호에 대한 정보를 토큰에 삽입하는 단계; 및 f) 다음 데몬으로 토큰을 전송하는 단계를 포함하는 링형 통신망에서 손실없는 메시지 전송방법을 제공한다.In order to achieve the above technical problem, the present invention provides a method for transmitting a message in a ring-type communication network, the method comprising the steps of: a) checking whether a request for transmission of a message not received in the token is received by the daemon; b) if there is a request to send a message, checking the client reception buffer to see if a message to be multicasted exists; c) storing the multicast message in the message management buffer according to the sequence number; d) searching for a message management buffer to check whether there is a message not received; e) inserting information about the entire sequence number into the token; And f) transmitting a token to a next daemon.

바람직하기로는 상기 단계 a)는 전송요청이 있으면 전송요청된 메시지가 자신의 관리버퍼에 있는지 확인하여 있으면 전송하고, 없으면 바로 단계 b)를 수행함을 특징으로 한다.Preferably, step a) is characterized in that if there is a transmission request, it checks whether the message requested to be sent is in its management buffer and transmits it, and if not, immediately performs step b).

더욱 바람직하기로는 상기 전송요청한 데몬이 1개이면 그 데몬에게만 유니캐스트하고, 1개 이상이면 멀티캐스트 함을 특징으로 한다.More preferably, if there is only one daemon requesting transmission, it is unicast only to that daemon, and if more than one daemon is multicast.

바람직하기로는 상기 멀티캐스트할 메시지가 존재하면 수신된 토큰에 포함된, 현재까지 망 내에서 멀티캐스된 전체 시퀀스번호의 다음번호부터 메시지에 인덱싱하여 메시지를 멀티캐스트 하고, 상기 멀티캐스트할 메시지가 존재하지 않으면 바로 단계 d)를 수행함을 특징으로 한다.Preferably, if the message to be multicasted exists, the message is multicasted by indexing the message from the next number of the entire sequence numbers multicasted in the network up to now, included in the received token, and the message to be multicasted exists. Otherwise, step d) is performed immediately.

더욱 바람직하기로는 수신하지 못한 메시지가 존재하면 수신하지 못한 메시 지의 시퀀스번호를 토큰정보에 삽입하고, 수신하지 못한 메시지가 존재하지 않으면 바로 단계 e)를 수행함을 특징으로 한다.More preferably, if there is an unreceived message, the sequence number of the unreceived message is inserted into the token information, and if the unreceived message does not exist, step e) is immediately performed.

바람직하기로는 상기 단계 e)에서 자신이 멀티캐스트한 메시지가 존재하지 않으면 수신된 토큰에 포함된 정보를 그대로 사용함을 특징으로 한다.Preferably, in step e), if the message multicasted by itself does not exist, the information included in the received token is used as it is.

이하 본 발명에 의한 링형 통신망에서 손실없는 메시지 전송방법에 대하여 첨부된 도면을 참조하여 보다 상세히 설명하기로 한다.Hereinafter, a method for transmitting a lossless message in a ring communication network according to the present invention will be described in detail with reference to the accompanying drawings.

도 1은 본 발명의 링형 통신망에서 손실없는 메시지 전송방법이 적용되는 통신시스템망을 개략적으로 도시한 구성도이다.1 is a block diagram schematically illustrating a communication system network to which a lossless message transmission method is applied in a ring communication network of the present invention.

도 1에 도시한 바와 같이, 손실없는 메시지 전송을 위하여 각 노드(컴퓨터)는 한 개의 데몬(100)과 여러 개의 클라이언트(CLIENT)(95)로 구성될 수 있다. As shown in FIG. 1, each node (computer) may be configured with one daemon 100 and several clients (CLIENT) 95 for lossless message transmission.

데몬(100)은 메시지 전송, 손실된 메시지 복구, 클라이언트관리, 다른 데몬에 대한 정보관리 등을 담당하는 일종의 서버를 말한다. 클라이언트는 이러한 데몬에 접속하여 자신이 전달하고자 하는 메시지를 원하는 목적지에 손실 없이 안전하게 전달하고 또한 전달 받을 수 있다. 손실없는 메시지 전송을 위하여 토큰 방식을 사용한다. 데몬들 사이에 토큰이 순차적으로 로테이션되고, 메시지 손실 방지 및 완전한 순서보장을 위하여 토큰을 가진 데몬만이 메시지를 네트워크상에 멀티캐스팅 할 수 있는 권리를 가진다. 또한 한 노드(컴퓨터)에서 토큰을 독점하는 것을 방지하기 위하여 데몬이 토큰을 가졌을 경우 멀티캐스트 할 수 있는 최대 메시지 수는 제한된다. 통상 데몬의 멀티캐스트 메시지수는 10개 내지 20개 정도이다.Daemon 100 is a kind of server that is responsible for message transmission, lost message recovery, client management, information management for other daemons. Clients can access these daemons to securely deliver and receive messages they want to deliver to their desired destinations. Token transmission is used for lossless message transmission. Tokens are rotated sequentially between daemons, and only the daemon with the token has the right to multicast messages across the network to prevent message loss and to ensure complete ordering. Also, to avoid monopolizing the token on one node (computer), the maximum number of messages that can be multicasted if the daemon has a token is limited. Normally, the number of daemon multicast messages is about 10-20.

도 1에 의하면, 데몬(100)내에서 데몬정보관리(10)는 데몬이 시작되면 네크 워크 상에 동작 중인 다른 데몬이 있는지 찾아서 만약 존재한다면 그에 대한 정보를 저장하고 토큰 로테이션 순서를 결정하는 역할을 수행한다.According to FIG. 1, the daemon information management 10 in the daemon 100 finds out if there is another daemon running on the network when the daemon starts, and if so, stores information about it and determines the token rotation order. Perform.

클라이언트 정보관리(20)는 클라이언트(95)가 데몬(100) 자신에게 접속되면 접속된 클라이언트에 대한 정보를 저장 관리한다.The client information management 20 stores and manages information on the connected client when the client 95 is connected to the daemon 100 itself.

메시지 관리버퍼(30)는 자신이 네크워크상에 멀티캐스팅한 메시지와 다른 데몬으로부터 멀티캐스팅되어 수신된 모든 메시지가 저장되며, 네트워크상에서 동작 중인 모든 데몬에서 동기화를 이루며 동일하게 관리된다.The message management buffer 30 stores all messages received by multicasting and received from other daemons on its own network, and is synchronized and managed in all daemons operating on the network.

클라이언트 수신버퍼(40)는 클라이언트(95)로부터 TCP/IP연결(5)을 통하여 전송된 메시지가 저장된다.The client receive buffer 40 stores a message transmitted from the client 95 via the TCP / IP connection 5.

메시지전송(멀티캐스트)(70)은 데몬(100)이 이전 데몬으로부터 토큰(3)을 수신하면(80) 클라이언트 관리(50) 및 클라이언트수신버퍼(40)를 확인하여 메시지가 존재하면 해당 메시지를 네트워크상(9)에 멀티캐스트 전송하며(70), 멀티캐스트한 메시지는 메시지 관리버퍼(30)에 저장한다. 메시지를 멀티캐스트 전송할 때에는 각 메시지에 순서대로 시퀀스 번호를 삽입하여 멀티캐스트하고 멀티캐스트가 완료된 메시지는 시퀀스 번호를 메시지 관리버퍼(30)의 인덱스 번호에 맞추어 메시지 관리버퍼(30)에 저장한다. 도 2에 도시한 바와 같이, 메시지 관리버퍼(30)의 인덱스 번호는 예를 들면 8000번 까지 있으며 8000번 다음부터는 0번부터 다시 시작된다. 도 2에서, 메시지 관리버퍼 인덱스번호가 1인 관리버퍼에는 메시지 시퀀스번호가 1인 메시지가 저장되고, 메시지 관리버퍼 인덱스번호가 2인 관리버퍼에는 메시지 시퀀스번호가 2인 메시지가 저장되고, 메시지 관리버퍼 인덱스번호가 3인 관리버퍼에는 메시지 시퀀스번호가 3인 메시지가 저장되고, 메시지 관리버퍼 인덱스번호가 4인 관리버퍼에는 메시지 시퀀스번호가 4인 메시지가 저장된다.The message transmission (multicast) 70 checks the client management 50 and the client receive buffer 40 when the daemon 100 receives the token 3 from the previous daemon (80) and if the message is present, retrieves the message. The multicast transmission (70) on the network (9), the multicast message is stored in the message management buffer (30). When multicasting a message, sequence numbers are inserted into each message in order to multicast, and the multicast-completed message is stored in the message management buffer 30 according to the index number of the message management buffer 30. As shown in FIG. 2, the index number of the message management buffer 30 is, for example, up to 8000 and starts again from 0 after 8000. In FIG. 2, a message having a message sequence number of 1 is stored in a management buffer having a message management buffer index number 1, a message having a message sequence number of 2 is stored in a management buffer having a message management buffer index number 2, and message management. The message having the message sequence number 3 is stored in the management buffer with the buffer index number 3, and the message with the message sequence number 4 is stored in the management buffer with the message management buffer index number 4.

메시지수신(멀티캐스트)(60)은 다른 데몬으로부터 UDP(User Datagram Protocol) 멀티캐스팅된 메시지(6)를 수신하고, 수신된 메시지의 시퀀스 번호를 확인하여 해당되는 메시지 관리버퍼(30)에 저장한다.The message receiving (multicast) 60 receives the UDP (User Datagram Protocol) multicasted message 6 from another daemon, checks the sequence number of the received message, and stores the received message number in the corresponding message management buffer 30. .

토큰 수신(80)시, 토큰에는 이전 데몬에서 부여된 최종 메시지(30)의 시퀀스 번호에 대한 정보 및 수신하지 못한 메시지가 존재하는지 여부(재전송 요구) 등에 대한 정보가 포함되어 있다. 데몬은 토큰정보로부터 최종 메시지 시퀀스번호에 대한 정보를 구하고, 자신이 멀티캐스트를 할 경우 메시지에 최종 시퀀스번호 다음 번호부터 삽입하여 다른 데몬들로 멀티캐스트를 한다. 토큰 전송(90)시 토큰은 토큰 채널(12)을 통하여 다음 데몬으로 유니캐스트 된다. Upon receipt of the token 80, the token contains information about the sequence number of the last message 30 given by the previous daemon and whether there is a message that has not been received (retransmission request). The daemon obtains the information on the final message sequence number from the token information, and when the user multicasts, the daemon inserts the message after the final sequence number and multicasts it to other daemons. At token transfer 90 the token is unicast via the token channel 12 to the next daemon.

도 1에서, 클라이언트 수신버퍼(40)는 각 데몬에 접속되어 있는 클라이언트로부터 수신된 메시지가 저장되어 있으며, 데몬이 토큰을 수신하면 네트웍상의 다른 데몬들에게 멀티캐스트(전송)될 메시지를 저장한다.In FIG. 1, the client receiving buffer 40 stores a message received from a client connected to each daemon, and stores a message to be multicasted (transmitted) to other daemons on the network when the daemon receives a token.

메시지 관리버퍼(30)는 다른 데몬들에게 멀티캐스트(전송)한 메시지와 다른 데몬들로부터 멀티캐스트(수신)된 메시지가 저장된다. 결국 자신이 전송한 메시지와 수신한 메시지가 모두 저장된다. 메시지 관리버퍼(30)에 저장할 때는 메시지의 시퀀스번호와 관리버퍼의 인덱스번호를 일치시켜 저장한다. 수신하지 못한 메시지의 존재 여부를 판단하기 위하여 토큰에는 다음의 두가지 중요한 정보가 포함되어 있다. The message management buffer 30 stores messages multicasted (transmitted) to other daemons and messages multicasted (received) from other daemons. Eventually, both the message sent and the received message are saved. When storing in the message management buffer 30, the sequence number of the message and the index number of the management buffer match. To determine the existence of a message that has not been received, the token contains two important pieces of information:

첫째, 현재까지 전체 망 내에서 멀티캐스트된(전송된) 메시지 중에서 한개라도 수신하지 못한 데몬이 존재하는지 여부에 대한 정보를 포함한다. 만약 현재까지 전체 망 내에서 멀티캐스트된(전송된) 메시지 중에서 한개라도 수신하지 못한 데몬이 존재한다면 어떤 메시지를 수신하지 못했는지(수신하지 못한 메시지의 시퀀스번호), 수신하지 못한 데몬이 1개인지 여러 개인지 여부(1개라면 그 데몬에게만 유니캐스트, 1개 이상이라면 멀티캐스트)의 정보를 포함한다.First, it contains information on whether there is a daemon that has not received any of the multicasted (transmitted) messages in the whole network. If there are daemons that have not received any of the multicasted (transmitted) messages in the entire network so far, which message did not receive (sequence number of the unreceived message), and whether there is one daemon that did not receive it. Includes information about whether there are multiple individuals (unicast to only that daemon, multicast to more than one daemon).

둘째, 이전 데몬까지 멀티캐스트된 메시지의 전체 시퀀스번호를 포함한다. 토큰을 수신한 데몬은 메시지를 멀티캐스트 할때, 토큰에 포함된 전체 시퀀스번호의 다음번호부터 인덱싱하여 메시지를 멀티캐스트 한다.Second, it contains the full sequence number of the message multicasted up to the previous daemon. When a daemon receives a token, the daemon multicasts the message by indexing the next sequence number of the entire sequence number contained in the token.

도 3은 본 발명에 의한 링형 통신망에서 손실없는 메시지 전송방법의 특정예를 설명하기 위한 개념도이다. 도 3을 참조하여 본 발명의 링형 통신망에서 손실없는 메시지 전송방법에 대하여 설명하기로 한다.3 is a conceptual diagram illustrating a specific example of a lossless message transmission method in a ring communication network according to the present invention. A lossless message transmission method in a ring communication network of the present invention will be described with reference to FIG. 3.

데몬1(100)이 토큰을 소유했을 때 클라이언트수신버퍼(40)에 있는 메시지1를 시퀀스 번호 1을 삽입하여 멀티캐스트하고 데몬2(200)로 토큰을 전송한다. 다른 데몬들은 모두 메시지1을 정상적으로 수신하여 메시지관리버퍼(30)에 저장하였다. 메시지관리버퍼(30)에 저장할 때는 메시지의 시퀀스 번호에 따라 관리버퍼의 인덱스번호가 0번째부터가 아니고 1번째부터 저장되며 관리버퍼의 인덱스번호가 0번째에는 메시지의 시퀀스 번호가 맨 마지막 번째인 8000이 저장되며 계속 로테이션된다.When the daemon 1 (100) owns the token, the message 1 in the client reception buffer 40 is multicasted by inserting the sequence number 1 and the token is transmitted to the daemon 2 (200). All other daemons normally received message 1 and stored it in the message management buffer (30). When storing in the message management buffer 30, the index number of the management buffer is stored from the first, not from 0, according to the sequence number of the message. If the index number of the management buffer is 0, the sequence number of the message is the last 8000. Is saved and continues to rotate.

데몬1(100)로부터 토큰을 수신한 데몬2(200)는 메시지 클라이언트수신버퍼(40)에 있는 두 개의 메시지에 시퀀스번호 2와 3을 삽입하여 멀티캐스트하고 데몬 3(300)으로 토큰을 전송한다. 데몬3(300)을 제외한 다른 데몬들은 모두 메시지2와 3을 정상적으로 수신하여 메시지관리버퍼(30)에 저장하였지만 데몬3(300)은 메시지3을 정상적으로 수신하지 못하였다.Receiving a token from daemon 1 (100), daemon 2 (200) multicasts by inserting sequence numbers 2 and 3 into two messages in the message client reception buffer 40 and transmits the token to daemon 3 (300). . All other daemons except the daemon 3 (300) received messages 2 and 3 normally and stored in the message management buffer 30, but the daemon 3 (300) did not receive the message 3 normally.

토큰을 수신한 데몬3(300)은 클라이언트수신버퍼(40)에 있는 메시지에 시퀀스번호 4를 삽입하여 멀티캐스트 한다. 다른 데몬들은 모두 메시지4를 정상적으로 수신하였지만 데몬2(200)는 메시지4를 정상적으로 수신하지 못하였다. 메시지 전송 후 데몬3(300)은 자신이 메시지3을 수신하지 못하였기 때문에 메시지3에 대한 재전송 요구 정보를 토큰에 삽입하여 다음 데몬4(400)으로 전송한다. 수신하지 못한 메시지에 대한 판단은 자신이 수신한 토큰으로부터 최종 시퀀스 번호와 자신이 관리하고있는 메시지 관리버퍼에 삽입되어 있는 메시지의 수를 비교하여 시퀀스 번호 몇 번을 수신하지 못하였는지 판단한다.Daemon 3 (300) receiving the token multicasts by inserting the sequence number 4 into the message in the client receiving buffer (40). All other daemons received message 4 normally, but daemon 2 200 did not receive message 4 normally. After the message is transmitted, the daemon 3 300 inserts retransmission request information for the message 3 into the token and transmits it to the next daemon 4 400 because it has not received the message 3. The judgment on the message that has not been received compares the final sequence number with the number of messages inserted in the message management buffer managed by the token received from the token and determines how many times the sequence number has not been received.

토큰을 수신한 데몬4(400)는 토큰으로부터 재전송 요구에 대한 정보를 확인하여 메시지관리버퍼(30)의 해당 인덱스 값에 해당하는 메시지3을 데몬3(300)으로만 전송한다. 만약 데몬4(400) 자신도 메시지3을 수신하지 못하였다면 다음 데몬으로 토큰을 전송할 때 메시지3을 수신하지 못한 데몬이 1개 이상이라는 정보를 삽입하여 전송하고, 이 토큰을 수신한 데몬은 메시지 3을 수신하지 못한 데몬이 한 개 이상이라는 것을 알고 메시지3을 모든 데몬으로 멀티캐스트한다. (이미 메시지3을 수신한 데몬들은 이 메시지를 무시한다.) 데몬4(400)는 자신의 새로운 메시지 5를 멀티캐스트한다. 모든 데몬은 메시지5를 수신하여 메시지관리버퍼(30)에 저장하였다. 그 후 데몬4(400)는 데몬1(100)로 토큰을 전송한다.Upon receiving the token, the daemon 4 (400) checks the information on the retransmission request from the token and transmits only the message 3 corresponding to the corresponding index value of the message management buffer 30 to the daemon 3 (300). If the daemon 4 (400) does not receive the message 3 itself, when it sends a token to the next daemon, it inserts and sends information indicating that one or more daemons have not received the message 3, and the daemon receiving the token receives the message 3 Multicast message 3 to all daemons, knowing that there is more than one daemon that has not received a message. (Demons that have already received message 3 ignore this message.) Daemon 4 400 multicasts its new message 5. All daemons received the message 5 and stored it in the message management buffer 30. Then daemon 4 (400) sends a token to daemon 1 (100).

토큰을 수신한 데몬1(100)은 메시지6과 메시지7를 멀티캐스트 한다. 데몬2(200)를 제외한 모든 데몬은 메시지6과 7를 수신하여 해당 메시지관리버퍼(30)에 저장하였다. 데몬2(200)는 메시지6은 수신하지 못했으며 메시지7만 정상적으로 수신하였다. 그 다음 데몬1(100)은 데몬2(200)로 토큰을 전송한다.Daemon 1 (100) receiving the token multicasts Message 6 and Message 7. All daemons except the daemon 2 (200) received the messages 6 and 7 and stored in the message management buffer (30). Daemon 2 (200) did not receive message 6, only received message 7 normally. The daemon 1 (100) then sends a token to the daemon 2 (200).

토큰을 수신한 데몬2(200)는 자신의 새로운 메시지인 메시지8과 9를 멀티캐스트하고 자신이 수신하지 못한 4번과 6번 메시지에 대하여 재전송 요구를 한다. 그 다음 데몬3(300)으로 이러한 정보가 포함된 토큰을 전송한다.Daemon 2 (200) receiving the token multicasts its own new messages, messages 8 and 9, and requests retransmission for messages 4 and 6 that it did not receive. It then sends a token containing this information to daemon 3 (300).

토큰을 수신한 데몬3(300)은 재전송 요구가 있음으로 메시지관리버퍼(30)에서 해당 인덱스값에 해당하는 메시지 4와 6을 데몬2(200)로 전송한다. 그리고 자신의 새로운 메시지를 멀티캐스트 한다. 이러한 메시지 전송 흐름이 계속된다.Daemon 3 (300) receiving the token sends a message 4 and 6 corresponding to the index value in the message management buffer 30 to the daemon 2 (200) because of the retransmission request. It then multicasts its new message. This message transmission flow continues.

이상으로 손실없는 메시지 전송 동작에 대해서 설명한 바와 같이, 본 발명은 메시지 전송시 손실된 메시지를 각 데몬에서 토큰 수신시 판단하여, 재전송 요구 정보를 토큰에 삽입하여 다음 데몬으로 전송하여 손실된 메시지를 재전송받을 수 있다. As described above, a lossless message transmission operation is performed. The present invention determines a lost message at the time of receipt of a token at each daemon, inserts retransmission request information into the token, and then retransmits the lost message. I can receive it.

이하, 첨부된 도 4를 참조하여 토큰 수신시 처리 알고리즘에 대하여 설명하기로 한다.Hereinafter, a processing algorithm upon receiving a token will be described with reference to FIG. 4.

도 4는 본 발명의 토큰 수신시 처리 알고리즘을 설명하기 위한 흐름도이다. 도 4에서, 토큰이 수신되면 (400) 토큰 정보를 확인한다(402). 이 때 메시지에 대한 최종 시퀀스번호 및 재전송 요청 존재여부 확인한다.4 is a flowchart illustrating a processing algorithm upon receiving a token of the present invention. In Figure 4, the token is received (400) to confirm the token information (402). At this time, check the final sequence number of the message and whether there is a retransmission request.

토큰정보가 확인되면 재전송요청이 있는가를 확인하여 (404), 없으면 단계 418로 진행하고 있으면 단계 406으로 진행한다. 단계 404에서 재전송요청이 있으면, 메시지관리버퍼에 재전송요청된 메시지가 존재하는지 확인한다(406). 재전송요청된 메시지가 존재하는가를 확인하여(408), 존재하면 단계 412로 진행하고 존재하지 않으면 단계 410으로 진행한다. 단계 412에서 재전송요청된 데몬이 1개이상인가 확인하여 1개 이상이면 단계 416을 진행하고, 1개 이상이 아니면 단계 414로 진행한다. 단계 410에서는 해당 메시지를 수신하지 못한 데몬이 1개 이상이라는 정보를 셋팅하고 단계 418로 진행하고, 단계 414에서는 재전송요청한 데몬에게만 해당 메시지를 전송하고 단계 418로 진행하고, 단계 416에서는 모든 데몬에게 멀티캐스트 전송하고 단계 418로 진행한다.If the token information is confirmed, it is checked whether there is a retransmission request (404). If not, the process proceeds to step 418. If there is a retransmission request in step 404, it is checked whether a retransmission request message exists in the message management buffer (406). If there is a resend request message, it is checked 408, and if there is, it proceeds to step 412, and if not, proceeds to step 410. In step 412, if there is more than one daemon requested to be retransmitted, and if there is more than one, proceed to step 416, if not more than one proceeds to step 414. Step 410 sets the information that one or more daemons did not receive the message and proceeds to step 418. In step 414, the message is sent only to the daemon requesting the resend and the process proceeds to step 418. Cast and proceed to step 418.

단계 418에서 클라이언트수신버퍼에 새로운 메시지가 존재하는가를 확인하여, 존재하지 않으면 단계 424로 진행하고 존재하면 단계 420에서 메시지에 시퀀스번호를 삽입하여 멀티캐스트한다. 멀티캐스트한 메시지는 시퀀스번호에 따라 메시지 관리버퍼에 저장한다(422). 단계 424에서 자신의 메시지관리버퍼를 확인하여 수신하지 못한 메시지가 존재하는지 확인한다. 단계 426에서 수신하지 못한 메시지가 존재하면 단계 428로 진행하여 해당 메시지를 수신하지 못한 데몬이 1개 이상이라는 정보가 셋팅되어 있는지 확인한다. 단계 426에서 수신하지 못한 메시지가 존재하지 않으면 단계 436으로 진행한다. 단계 430에서 정보가 셋팅되어 있으면 단계 432에서 1개 이상의 데몬이 해당 메시지를 수신하지 못하였다는 정보를 토큰에 삽입하고 단계 434로 진행한다. 단계 434에서 해당 메시지에 대한 재전송요청정보를 토큰에 삽입하고 단계 436을 진행한다.In step 418, it is checked whether there is a new message in the client receiving buffer. If not, the process proceeds to step 424. If there is, in step 420, a sequence number is inserted into the message and multicasted. The multicast message is stored in the message management buffer according to the sequence number (422). In step 424, the message management buffer is checked to see if there is a message not received. If there is a message that has not been received in step 426, the flow proceeds to step 428 to determine whether information on one or more daemons that do not receive the message is set. If there is no message not received in step 426, the flow proceeds to step 436. If the information is set in step 430, in step 432, the information is inserted into the token that one or more daemons did not receive the message, and the flow proceeds to step 434. In step 434, the retransmission request information for the message is inserted into the token and the process proceeds to step 436.

단계 436에서 최종 시퀀스번호에 대한 정보를 토큰에 삽입하고 다음 데몬으로 토큰 전송한다(438). 그 다음 단계440에서 메시지관리버퍼에 있는 메시지를 클라이언트로 전송하고 토큰수신대기한다(442).In step 436, information about the final sequence number is inserted into the token and the token is transmitted to the next daemon (438). Next, in step 440, the message in the message management buffer is transmitted to the client and the token reception waits (442).

도 5는 본 발명의 멀티캐스트 수신시 처리 알고리즘을 설명하기 위한 흐름도이다. 5 is a flowchart illustrating a processing algorithm upon multicast reception according to the present invention.

도 5에서 멀티캐스트 수신하면(500), 수신된 메시지의 시퀀스번호를 확인하고(510), 그 다음 시퀀스번호에 따라 메시지관리버퍼에 저장하고(520), 메시지관리버퍼에 있는 메시지를 클라이언트에 전송하고(530), 멀티캐스트 수신 대기한다(540).When receiving the multicast in FIG. 5 (500), the sequence number of the received message is checked (510), and then stored in the message management buffer according to the sequence number (520), and the message in the message management buffer is transmitted to the client. In step 530, the multicast reception signal is waited for (540).

일반적으로 UDP통신은 접속(CONNECTION)이 필요없기 때문에 편리한 점이 있는 반면에 메시지 손실이 발생 할 가능성이 존재한다. 이러한 메시지 손실 방지를 위하여 많은 비용을 투자하여 하드웨어적으로 해결하거나 복잡한 알고리즘을 통하여 시스템을 복잡하게 구성하는 경우가 많다. 그러나 본 발명에서는 단순한 알고리즘 사용과 멀티캐스트를 통한 전송속도의 개선을 통하여 네트워크상에서 보다 간편하게 손실없는 메시지전송을 가능하게 한다. In general, UDP communication is convenient because it does not require a connection, but there is a possibility of message loss. In order to prevent such a message loss, a large amount of money is often solved by hardware or a system is complicated by a complex algorithm. However, in the present invention, lossless message transmission is more easily performed on a network by using a simple algorithm and improving a transmission speed through multicast.

Claims (5)

링형 통신망에서 메시지 전송방법에 있어서,In the message transmission method in a ring communication network, a) 데몬이 토큰을 수신하면 토큰에 수신하지 못한 메시지의 전송요청이 있는지 확인하는 단계;a) if the daemon receives the token, checking whether there is a request for transmission of a message not received in the token; b) 메시지의 전송요청이 있는 경우, 클라이언트수신버퍼를 확인하여 자신이 멀티캐스트할 메시지가 존재하는지 확인하는 단계;b) if there is a request to send a message, checking the client reception buffer to see if a message to be multicasted exists; c) 멀티캐스트한 메시지를 시퀀스번호에 맞게 메시지 관리버퍼에 저장하는 단계;c) storing the multicast message in the message management buffer according to the sequence number; d) 메시지 관리버퍼를 검색하여 수신하지 못한 메시지가 존재하는지 확인하는 단계;d) searching for a message management buffer to check whether there is a message not received; e) 전체 시퀀스번호에 대한 정보를 토큰에 삽입하는 단계; 및e) inserting information about the entire sequence number into the token; And f) 다음 데몬으로 토큰을 전송하는 단계를 포함하는 링형 통신망에서 손실없는 메시지 전송방법.f) Lossless message transmission in a ring network comprising the step of sending a token to the next daemon. 제1항에 있어서, 상기 단계 a)는 전송요청이 있으면 전송요청된 메시지가 자신의 관리버퍼에 있는지 확인하여 있으면 전송하고, 없으면 바로 단계 b)를 수행함을 특징으로 하는 링형 통신망에서 손실없는 메시지 전송방법.The method of claim 1, wherein the step a) transmits a lossless message in a ring-type communication network, in which if a transmission request is made, the message requested to be transmitted is checked in its management buffer, and if there is no transmission, the process is performed immediately. Way. 제2항에 있어서, 상기 전송요청한 데몬이 1개이면 그 데몬에게만 유니캐스트 하고, 1개 이상이면 멀티캐스트 함을 특징으로 하는 링형 통신망에서 손실없는 메시지 전송방법.The method of claim 2, wherein if there is only one daemon requesting transmission, unicast only to the daemon, and if more than one daemon transmits one or more daemons, multicasting is performed. 제1항에 있어서, 상기 멀티캐스트할 메시지가 존재하면 수신된 토큰에 포함된, 현재까지 망 내에서 멀티캐스된 전체 시퀀스번호의 다음번호부터 메시지에 인덱싱하여 메시지를 멀티캐스트 하고, 상기 멀티캐스트할 메시지가 존재하지 않으면 바로 단계 d)를 수행함을 특징으로 하는 링형 통신망에서 손실없는 메시지 전송방법.The multicast message according to claim 1, wherein if the message to be multicasted is present, the message is multicasted by indexing the message from the next number of the entire sequence numbers multicasted in the network up to now. And if there is no message, performing step d) immediately. 제1항에 있어서, 상기 단계 e)에서 자신이 멀티캐스트한 메시지가 존재하지 않으면 수신된 토큰에 포한된 정보를 그대로 사용함을 특징으로 하는 링형 통신망에서 손실없는 메시지 전송방법.The method of claim 1, wherein the information contained in the received token is used as it is if the message multicasted by the user in step e) does not exist.
KR1020050060880A 2005-07-06 2005-07-06 Message transmission method without loss in ring-type communication network KR100921491B1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
KR1020050060880A KR100921491B1 (en) 2005-07-06 2005-07-06 Message transmission method without loss in ring-type communication network

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR1020050060880A KR100921491B1 (en) 2005-07-06 2005-07-06 Message transmission method without loss in ring-type communication network

Publications (2)

Publication Number Publication Date
KR20070005844A KR20070005844A (en) 2007-01-10
KR100921491B1 true KR100921491B1 (en) 2009-10-13

Family

ID=37871223

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020050060880A KR100921491B1 (en) 2005-07-06 2005-07-06 Message transmission method without loss in ring-type communication network

Country Status (1)

Country Link
KR (1) KR100921491B1 (en)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101616080B (en) * 2009-07-17 2011-06-22 北京星网锐捷网络技术有限公司 Packet order preserving method of resilient packet ring, device and network equipment

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0701346A2 (en) 1994-09-09 1996-03-13 ABBPATENT GmbH Method for consistent data transmission
JPH10210032A (en) 1997-01-24 1998-08-07 Matsushita Electric Ind Co Ltd Broadcast method
KR20020051396A (en) * 2000-12-22 2002-06-29 엘지전자 주식회사 Multicast structure and its method using ring structure
US20030061389A1 (en) 2001-09-26 2003-03-27 Sam Mazza Multi-token totally ordered group communication protocol

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0701346A2 (en) 1994-09-09 1996-03-13 ABBPATENT GmbH Method for consistent data transmission
JPH10210032A (en) 1997-01-24 1998-08-07 Matsushita Electric Ind Co Ltd Broadcast method
KR20020051396A (en) * 2000-12-22 2002-06-29 엘지전자 주식회사 Multicast structure and its method using ring structure
US20030061389A1 (en) 2001-09-26 2003-03-27 Sam Mazza Multi-token totally ordered group communication protocol

Also Published As

Publication number Publication date
KR20070005844A (en) 2007-01-10

Similar Documents

Publication Publication Date Title
US9900168B2 (en) System and method for reliable multicast data transport
US7502860B1 (en) Method and apparatus for client-side flow control in a transport protocol
CN102685204B (en) Method and equipment for transmitting data resource
US7554992B2 (en) Mobile device communications system and method
US5553083A (en) Method for quickly and reliably transmitting frames of data over communications links
US7948921B1 (en) Automatic network optimization
US9641492B2 (en) Protocol link layer
JP4856344B2 (en) System and method for displaying and maintaining redundant data sets utilizing DNA transmission (transmission) and transcription techniques
US20030039249A1 (en) Method and system for efficient layer 3-layer 7 routing of internet protocol (&#34;IP&#34;) fragments
Zhu et al. Chronos: Serverless multi-user chat over NDN
JPH11161622A (en) Communication system
US20050039048A1 (en) Efficient new e-mail discovery
US7539191B1 (en) System and method for securing route processors against attack
CN106059936B (en) The method and device of cloud system Multicast File
JP2005025758A (en) System and method for message-based scalable data transfer
CN112152914A (en) Instant messaging method and system based on Beidou short message
Natarajan et al. SCTP: What, why, and how
US8453229B2 (en) Push type communications system
CN110771117B (en) Session layer communication using ID-oriented network
US20040267960A1 (en) Force master capability during multicast transfers
KR100921491B1 (en) Message transmission method without loss in ring-type communication network
CN109792444B (en) Play-out buffering in a live content distribution system
Cameron et al. Transport multiplexing protocol (tmux)
Waters et al. The interactive sharing transfer protocol version 1.0
Gómez Montenegro et al. Constrained Application Protocol (CoAP) over Bundle Protocol (BP)

Legal Events

Date Code Title Description
A201 Request for examination
A302 Request for accelerated examination
E701 Decision to grant or registration of patent right
GRNT Written decision to grant
FPAY Annual fee payment

Payment date: 20120928

Year of fee payment: 4

FPAY Annual fee payment

Payment date: 20130930

Year of fee payment: 5

FPAY Annual fee payment

Payment date: 20140929

Year of fee payment: 6

FPAY Annual fee payment

Payment date: 20150930

Year of fee payment: 7

FPAY Annual fee payment

Payment date: 20160929

Year of fee payment: 8

FPAY Annual fee payment

Payment date: 20170928

Year of fee payment: 9

FPAY Annual fee payment

Payment date: 20181001

Year of fee payment: 10

FPAY Annual fee payment

Payment date: 20191001

Year of fee payment: 11