KR100248080B1 - 다자간 멀티미디어 통신에서의 에러제어 방법 - Google Patents
다자간 멀티미디어 통신에서의 에러제어 방법 Download PDFInfo
- Publication number
- KR100248080B1 KR100248080B1 KR1019970051198A KR19970051198A KR100248080B1 KR 100248080 B1 KR100248080 B1 KR 100248080B1 KR 1019970051198 A KR1019970051198 A KR 1019970051198A KR 19970051198 A KR19970051198 A KR 19970051198A KR 100248080 B1 KR100248080 B1 KR 100248080B1
- Authority
- KR
- South Korea
- Prior art keywords
- source
- data
- receiver
- error
- heartbeat
- Prior art date
Links
- 238000000034 method Methods 0.000 title claims abstract description 64
- 238000004891 communication Methods 0.000 title claims abstract description 33
- 230000004044 response Effects 0.000 claims description 22
- 238000012937 correction Methods 0.000 claims description 19
- 239000000872 buffer Substances 0.000 claims description 17
- 230000007704 transition Effects 0.000 claims description 13
- 230000007246 mechanism Effects 0.000 claims description 6
- 230000005540 biological transmission Effects 0.000 abstract description 39
- 101000741965 Homo sapiens Inactive tyrosine-protein kinase PRAG1 Proteins 0.000 abstract description 19
- 102100038659 Inactive tyrosine-protein kinase PRAG1 Human genes 0.000 abstract description 19
- 238000001514 detection method Methods 0.000 abstract description 14
- 230000006870 function Effects 0.000 abstract description 12
- 238000013016 damping Methods 0.000 abstract description 10
- 238000011084 recovery Methods 0.000 abstract description 7
- 230000008569 process Effects 0.000 description 13
- 238000010586 diagram Methods 0.000 description 9
- 238000012986 modification Methods 0.000 description 6
- 230000004048 modification Effects 0.000 description 6
- 238000012545 processing Methods 0.000 description 5
- 238000007726 management method Methods 0.000 description 4
- 230000008901 benefit Effects 0.000 description 3
- 230000009471 action Effects 0.000 description 2
- 230000008859 change Effects 0.000 description 2
- 238000011161 development Methods 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 238000011160 research Methods 0.000 description 2
- 238000013459 approach Methods 0.000 description 1
- 230000003139 buffering effect Effects 0.000 description 1
- 230000015556 catabolic process Effects 0.000 description 1
- 239000003795 chemical substances by application Substances 0.000 description 1
- 238000012790 confirmation Methods 0.000 description 1
- 238000006731 degradation reaction Methods 0.000 description 1
- 230000001934 delay Effects 0.000 description 1
- 230000003111 delayed effect Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 230000010365 information processing Effects 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 239000012464 large buffer Substances 0.000 description 1
- 230000007774 longterm Effects 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
Images
Classifications
-
- 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
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Communication Control (AREA)
Abstract
본 발명은 다자간 멀티미디어 통신에서의 에러제어 방법에 관한 것이다.
기존의 송수신자간의 데이터 전송시 발생되는 에러를 발견하고 해결하는 에러제어 방법에는 에러검출, 에러보고 및 에러복구 기능들이 있으나, 이들 기능들은 단순히 하나의 송신자와 하나의 수신자로 구성된 단-대-단 통신에서 발생하는 에러제어 방식으로, 멀티미디어 환경과 같이 다-대-다의 다지점, 다자간 통신에서 하나 또는 몇 개의 송신자와 많은 수신자들 사이에서 동시 다발적으로 발생하는 에러들을 해결하는 데는 적합하지 않다.
따라서, 본 발명에서는 NACK을 기반으로 하여 에러를 감지한 모든 수신자가 동시에 재전송을 요구하는 에러제어 패킷의 수를 최소화하도록 댐핑 기술을 사용한다.
Description
본 발명은 멀티미디어 컴퓨터 통신에서 초고속화되는 망의 성능과 컴퓨터의 컴퓨팅 속도에 비해 망을 접속하여 상호간에 통신하는 컴퓨터간의 통신에서 병목현상을 초래하고 있는 기존의 전송 프로토콜을 대체하기 위한 에러제어 방법에 관한 것으로, 특히 다-대-다(many-to-many)의 통신 모델을 지원하는 전송 프로토콜에서 다자간의 신뢰성 있는 데이터 전송을 보장하기 위한 에러제어 방법에 관한 것이다.
세계의 지구촌화를 추구하는 최근의 동향은 한 국가내의 많은 지역, 그리고 전세계의 국가 사이를 통신과 정보처리를 통해 상호 밀착화되고 있다. 이러한 요구사항들은 기존의 통상적인 메일, 전화, 팩스를 통해서는 간단히 해결되지 않고, 원격강의, 원격진료, 원격 화상회의 등과 같은 응용 서비스를 통해 얼굴과 얼굴을 맞대고 동시에 대화를 할 수 있는 그룹 공동작업을 지원하는 그룹웨어등 다양한 멀티미디어 응용 서비스들을 요구하고 있다.
고속화되고 다양화를 추구하는 응용 서비스들을 공동으로 분할하여 사용하기 위한 한가지 접근 방법은 다수의 사용자를 위한 전송 프로토콜을 개발하는 것이다. 그러나 대부분의 경우 참가하는 사용자들에게 기존의 사용자와 시스템간 상호 작용만을 지원하는 싱글-유저를 공유하는 1:1 전송 프로토콜 방식이 대부분이었다. 이를 해결하려는 노력의 일환으로 최근의 통신망과 응용 서비스 분야는 전송 프로토콜을 중요한 연구영역으로 부각시키고 있고, 고속 전송 프로토콜은 이기종 고속망에서의 멀티미디어 응용을 위한 새로운 연구 분야로 대두되고 있다. 기존의 OSI TP(Transport Protocol)4 스택이나, TCP/IP는 일반적인 텍스트 데이터를 전송하기 위해 제정된 프로토콜로서 멀티미디어 환경에서 요구되는 실시간 통신 및 다량의 데이터를 신뢰성있게 처리하기 위한 통신을 제공하기에는 적합하지 않은 단점을 많이 가지고 있다. 또, 이들 프로토콜들은 다양한 컴퓨터 통신망의 증가, 통신기술의 발달과 전송장치의 개발에 따른 전송속도의 증가, 컴퓨터 기술의 발달 그리고 다양한 미디어를 포함한 새로운 응용 서비스 영역의 확장으로 이에 수반되는 요구 사항들을 만족시킬 수 있는 통신 프로토콜로는 적합하지 않다. 또한 이들은 망의 대역폭이 좁고 에러 발생율이 높으며, 시스템 자원이 부족하던 시기에 개발되었기 때문에 대역폭의 효율적 사용과 에러의 발견 및 회복을 효율적으로 수행하는 것이 주된 목표였다. 그러나 현재의 고속 통신망 환경은 기존 프로토콜의 구조적인 문제점으로 인하여 발생하는 성능 저하를 해결하기 위하여 기존 프로토콜의 기능을 변경하거나 확장하고, 프로토콜 처리시간을 최소화하는 방법과 현재의 고속망 환경에 알맞게 구조화된 새로운 프로토콜을 설계하는 방법등이 동원되고 있다. 이중 기존 프로토콜의 확장은 장기적인 해결책이 못되므로 새로운 프로토콜 설계에 대한 연구가 최근에 활발하게 연구되고 있다.
에러제어는 멀티미디어 컴퓨터 통신의 다자간 전송 프로토콜 환경에서 협동작업등 멀티미디어 응용에 필요한 데이터 전송을 신뢰성있게 제공하게 하기 위한 것이다. 기존의 에러제어 방식들은 지터, 지연등 망의 상태가 불안전하고 속도등의 성능이 열악하던 시기에 문서위주의 텍스트 데이터들을 주대상으로 사용되어 왔기 때문에, 현재의 멀티미디어와 초고속화된 전송망을 기반으로 하는 초고속 정보통신 환경에서 요구하는 에러제어 방식으로 사용하기에는 많은 단점들이 나타나고 있다.
다자간의 신뢰성 있는 데이터 전송을 보장하기 위해서는 데이터 패킷 전송의 신뢰성을 보장해야 하며, 통신에 가입하고 있는 그룹 멤버쉽의 신뢰성을 보장해야 한다. 이러한 유형의 신뢰성을 제공하기 위해서는 전송제어 프로토콜(Transmission Control Protocol; TCP)과 같은 일-대-일(end-to-end 또는 peer-to-peer) 통신을 기반으로 하는 프로토콜에서 발생하지 않는 확인 메시지 폭주(ACKnowledge implosion) 문제와 그룹 멤버쉽의 확장성(scalability) 문제를 고려하여야 한다.
오디오/비디오 회의등과 같은 실시간 응용 프로그램은 신뢰성있는 전송 서비스 대신 엄격한 전송 지연 서비스를 보장 받기 원한다. 한편, 공동 편집기나 의료 영상 정보등의 분배등과 같은 협동 처리 용용프로그램(collaborative application)에 있어서는 신뢰성을 보장하는 전송 서비스를 절대적으로 요구한다. 이러한 신뢰성 보장을 필요로 하는 응용 프로그램의 요구를 수용하기 위해서 최근 다양한 형태의 신뢰성있는 멀티캐스트 전송 프로토콜이 개발되었고, 이들을 비교 분석한 연구 결과도 있으나, 이러한 프로토콜들은 그룹 크기의 확장성(scalability)과 신뢰성 문제를 효과적으로 해결하지 못하고 있다
기존의 송신자와 수신자가 1:1 연결을 설정하여 상호간에 데이터를 주고 받는 단-대-단(end-to-end) 통신에서는 신뢰성있게 데이터를 송수신하는 방법으로 송신자의 데이터를 수신자가 수신한 후, 수신한 데이터의 상태를 송신자에게 응답함 으로서 이루어진다. 에러제어는 이들 송수신자간의 데이터 전송시 발생하는 에러들을 발견하고 해결하는 기능이다. 송수신 과정에서 발생할 수 있는 에러에는 전송된 패킷 내용의 변형, 패킷이 도착하는 순서의 변화, 중복된 패킷의 도착, 패킷의 손실등이다. 이러한 에러제어 기능은 에러검출, 에러보고, 에러복구(수정)등의 3가지 기능으로 다음과 같은 연구가 선행되었다.
에러검출 기능은 패킷들이 내용의 변형없이 전송된 순서대로 도착하는가를 검사하는 기능이다. 에러검출을 위해서는 시퀀스 넘버, 패킷의 길이, 그리고 데이터 첵섬과 같은 정보를 이용하여 하나의 메시지를 받고 이를 검사한 후, 다음 순서의 메시지를 받는 절차를 갖는다.
에러보고 기능은 잘못된 패킷의 도착이나 손실된 패킷에 관한 정보를 송신측에 전달하는 기능으로서 패킷이 도착할 때마다 응답을 실시하는 확인(Acknowledge: 이하 ACK라 함) 방식보다는, 에러가 발생한 패킷만을 선택하여 응답하는 소극적 확인(Negative Acknowledge: 이하 NACK이라 함) 방식이 잘 알려져 있다. 일반적으로 기존 프로토콜에서는 이러한 에러보고 기능을 보유하지 않고 일정한 기간내에 수신자가 송신자에게 확실하게 응답을 실시하는 적극적 확인(Positive Acknowledge: 이하 PACK이라 함) 패킷의 도착 여부로 에러를 수시로 검출하기 때문에 이를 다-대-다(many-to-many) 통신에 적용할 경우 데이터 전송시 과부하의 원인이 되고 있다.
에러복구(수정) 기능은 보고된 에러를 재전송하여 복구하는 기능이다. 에러가 발생한 패킷 이후의 모든 패킷을 재전송하는 방식을 사용하며, 구현이 간단하여 에러율이 높은 통신망에 적용이 용이하므로 기존 프로토콜들에서 채택되어 사용되고 있으나, 현재의 망의 신뢰성이 향상되고 짧은 시간에 다량의 데이터를 전송해야 하는 초고속망 환경에서는 수정된 방법이 필요하다.
상기와 같은 기능들은 단순히 하나의 송신자와 하나의 수신자로 구성된 단-대-단(end-to-end) 통신에서 발생하는 에러제어 방식으로 멀티미디어 환경과 같이 다-대-다(many-to-many)의 다지점, 다자간 통신에서 하나 또는 몇 개의 송신자와 많은 수신자들 사이에서 동시 다발적으로 발생하는 에러들을 해결하는 데는 적합하지 않은 방법이다.
본 발명은 멀티미디어 컴퓨터 통신 환경에 맞는 에러제어 기법들을 사용하여 데이터의 신뢰성 있는 송수신을 향상시키므로써 다지점, 다자간 통신 환경에서 여러 가지 멀티미디어 응용 서비스들을 위한 요구 조건을 만족시킬 수 있는 에러제어 방법을 제공하는데 그 목적이 있다.
상술한 목적을 달성하기 위한 본 발명은 소스로부터 데이터와 하트비트를 수신한 수신자가 상기 데이터 및 하트비트를 분석하여 데이터 접수에서 에러가 발생하였는지를 검사하는 제 1 단계와, 상기 제 1 단계의 검사 결과 데이터 접수에서 에러가 발생했을 경우 소스로부터 데이터와 하트비트를 재수신하고, 에러가 발생하지 않았을 경우 시퀀스 넘버 영역밖의 데이터 패킷을 수신하였는지를 검사하는 제 2 단계와, 상기 제 2 단계의 검사 결과 시퀀스 넘버 영역내의 데이터 패킷을 수신하였을 경우 수신한 데이터와 하트비트를 분석하는 단계로 천이하고, 수신자가 시퀀스 영역 밖의 데이터 패킷을 수신하였을 경우 에러 수정 메카니즘을 구동하는 제 3 단계와, 상기 에러 수정 메카니즘을 구동한 후 수신자가 소스로부터 재전송 요청을 위한 문턱값 이내에 어떠한 메시지라도 수신할 경우 수신한 데이터와 하트비트를 분석하는 단계로 천이하고, 아무것도 수신하지 못하였을 경우 수신자가 멀티캐스트 그룹에 쿼리 메시지를 전송하여 소스의 상태에 대해 문의하는 제 4 단계와, 상기 쿼리에 대한 응답으로 소스가 하트비트를 전송하고, 소스로부터 수신되는 데이터 패킷에 에러가 있을 경우 소스로부터 데이터 및 하트비트를 수신하는 단계로 천이하고, 더 이상 데이터 패킷에 에러가 없을 경우 종료하는 제 5 단계를 포함하여 이루어진 것을 특징으로 한다.
도 1은 본 발명에 따른 전송 프로토콜 내부의 상태 흐름도.
도 2는 본 발명에 따른 에러 검출과 재전송 요청을 위한 상태 흐름도.
도 3은 본 발명에 따른 에러 수정을 위한 상태 흐름도.
도 4는 본 발명이 적용되는 멀티미디어 통신 시스템에서의 프로토콜 상하위 구조도.
도 5는 본 발명에 따른 에러 검출과 재전송 요청의 처리 흐름도.
도 6은 본 발명에 따른 에러 수정의 처리 흐름도.
〈도면의 주요 부분에 대한 부호 설명〉
101 : 송신 상태 102 : 하트비트 상태
103 : 종료 상태 104 : 닫기 상태
105 : 대기 1 상태 106 : 송신 복구 상태
107 : 경청 상태 108 : 시작 실패 상태
109 : 수신 상태 110 : 대기 2 상태
111 : 대기 3 상태
통신에 참여하는 사용자는 소수의 소스(Source)와 다수의 수신자(Receivers)로 통신그룹을 구성하며, 이들간에 통신을 위한 연결을 설정하여 데이터를 송수신하게 된다. 데이터 전송중에는 전송 메시지를 손실(파손 및 분실을 의미)하는 경우와 네트워크 트래픽 폭주 및 고장과 시스템 다운등 양단말간에 설정된 시스템의 갑작스러운 환경변화로 인한 에러가 발생하게 되어 이를 검출하고 수정 및 복구하는 과정이 필요하다. 본 발명에서는 이들 과정을 다음과 같이 에러검출 방식과 에러수정 방식으로 분류한다.
1. 에러검출 방식
에러검출 방식에는 데이터 패킷 에러제어 방법과 호스트 시스템 에러제어 방법이 있다.
가. 데이터 패킷(Message failure) 에러제어 방법
이 방법은 소스와 수신자들간에 전송된 메시지에 대한 에러만을 취급한다. 소스와 수신자는 메시지의 시퀀스 넘버를 사용하여 송수신한 데이터를 인식한다. 시퀀스 넘버는 숫자로 시작, 각 데이터 패킷마다 식별을 위해 순차적으로 증가하며, 각 소스가 독립적으로 유지하도록 한다. 수신자는 시퀀스 넘버간의 간격(gap)을 찾는 방법으로 분실을 검출하고 데이터 패킷의 첵섬값으로 패킷의 파손을 발견한다.
하트비트 메시지는 소스 호스트의 존재와 상태 표시에 사용한다. 통신을 시작하고 최초로 보내는 하트비트 메시지는 소스 호스트만이 전송하며, 마지막 패킷의 시퀀스 넘버에 포함된다.
하트비트를 발생하는 경우는 다음과 같다. 하트비트는 소스가 데이터를 전송하지 않을 때 발생하며, 소스의 데이터 손실 발생을 수신자가 인식하게 하고, 소스의 정지시간, 소스의 활동 사항등을 나타낸다. 그리고 어떤 소스가 일정 기간동안 잠시 정지할 때 사용한다. 소스가 일정 기간동안 전송을 중지할 때는 정상으로 전송될 때까지 하트비트를 규칙적으로 전송한다.
소스의 하트비트 송신에 대해 수신자는 이 소스의 하트비트 메시지를 임의의 요청(request)에 대해 응답하는 지시(indication)로 사용한다. 소스, 수신자들간 연결이 단절되지 않고 여전히 설정되어 있지만, 어떤 이유로 인해 소스가 데이터 전송을 억제하는 경우에는 일정기간이 경과한 후, 즉 하트비트 메시지 시작 전에 NACK의 양, 흐름제어(flow control) 파라미터, 왕복배달에 걸리는 시간등의 상수들을 계산한다.
회의 참가자들은 대부분 소량의 메시지를 전송하게 되며, 실제로 멀티캐스트 세션기간중 가끔씩 전송을 실시하게 되는데, 이때는 하트비트 전송시간을 제한한다. 이들 소스는 특정시간 동안만 10개의 메시지를 송신한 후 더 이상 소스가 아님을 선언한다.
수신자들은 소스의 기본상태(source reference state)를 내부적으로 참조하게 되며, 만약 수신자가 이들 메시지를 얻는데 실패하고, 소스에게 상태개선을 요청하면 소스는 그 정보를 다시 반복한다. 일정시간 경과후 호스트는 소스에서 수신자로 전이하는데, 수신자의 데이터 동기는 세션과 응용계층의 책임이며, 소스는 더 이상 하트비트 메시지를 전송하지 않는다.
소스는 그룹에서 수신자에 대한 모든 정보를 유지하며, 수신자는 소스에 대한 상태관련 정보를 계속 유지한다. 소스는 수신자에 관한 정보 유지를 위해 하트비트 메시지를 멀티캐스트로 전송하며, 수신자도 소스에게 주기적으로 하트비트 메시지를 송신하여 수신자가 수신한 마지막 메시지를 알리도록 한다. 수신자가 보내는 하트비트 정보는 소스만이 받을수 있고 다른 수신자는 할 수 없으며, 수신자는 소스에게 하트비트를 유니캐스트(Unicast)로 전송한다. 이 하트비트에는 수신자 ID와 콘넥션의 포트 넘버를 포함하며, 수신자가 수신한 마지막 메시지의 시퀀스 넘버도 포함한다. 소스는 여러 수신자로부터 오는 하트비트 폭주를 피하기 위한 방법으로 주기적으로 하나의 수신자만 선택하는 무작위(Randomized) 방법을 사용한다.
소스는 수신자가 보내는 하트비트를 수신자의 상태추적을 유지하는데 사용하며, 소스는 여러 다른 수신자로 부터도 무작위(Randomized) 방법에 의해 오버헤드를 줄여 수신한 하트비트로 수신자의 상태정보를 수집하고, 자신의 상태 테이블에 그룹 멤버들의 리스트를 만든다. 그리고, 그룹내의 모든 수신자들은 소스가 보낸 첫 번째 하트비트 메시지를 이용하여 수신자 자신들도 소스에 대한 상태 테이블을 설치한다. 이렇게 하여 얻은 상태에 관한 정보들은 상위 계층에게 통보한다. 소스는 상태 테이블(state tables)을 유지하며, 이는 가입절차, 탈퇴절차, 흐름제어, 에러제어등 통신 전반에 걸친 신뢰성을 보장하기 위한 기반이 된다. 소스는 수신자가 대화를 중단하면 응용 계층에게 이를 알린다. 수신자가 떠났다고 소스가 한번 결정하면, 수신자 리스트에서 수신자를 제거하고, 변경을 응용 계층에게 통보한다.
소스의 하트비트에는 소스 ID와 마지막 메시지의 시퀀스 넘버, 포트 넘버를 포함한다. 수신자는 소스가 보낸 메시지를 트랙하기 위해 첫 번째 데이터 패킷의 시퀀스 넘버를 사용한다. 수신자는 소스에서 수신된 첫 번째 메시지에 응답하기 위해 소스에게 유니캐스트(Unicast) 어드레스로 하트비트 메시지를 전송한다. 이 하트비트 메시지는 주기적으로 반복되며, 이는 하트비트 이외에는 소스의 확실한 ACK이 없기 때문이다. 소스는 보낼 데이터 패킷이 없을 때 이 하트비트를 전송하며, 수신자에게 하트비트 기간내에 응답을 보내도록 요구한다.
소스의 첫 번째 데이터 접수후, 수신자의 하트비트 메시지 사용은 응용 계층에게 신뢰성 제공과 수신자 상태 유지를 위한 상태 테이블(State Table) 작성에 필요하다.
종합적으로 요약을 하면 소스가 수신하는 수신자 하트비트는 전체 수신자가 보내는 하트비트들이 네트워크에서 포화되는 것을 피하기 위해 소스에서 랜덤화하여 수신한다.
수신자의 하트비트는 소스에게 유니캐스트(unicast)로 전송되며, 소스가 보낸 마지막 메시지에 대한 통보 뿐만 아니라, 이를 이용하여 소스가 전체 수신자들의 그룹 멤버쉽을 관리할 수 있는 정보를 제공한다. 이 하트비트 메시지는 주기적으로 반복되며, 이는 하트비트 이외에는 소스의 확실한 ACK가 없기 때문이다. 소스는 보낼 데이터 패킷이 없을 때 이 하트비트를 전송하며, 수신자에게 하트비트 기간내에 응답을 보내도록 요구한다.
나. 호스트 시스템(Site failure) 에러제어 방법
이 방법은 소스와 수신자들의 상태에 대한 에러 제어 방법이다. 수신자는 소스의 하트비트 메시지를 포함한 데이터의 수신이 중단된 경우, 소스의 상태를 파악하기 위해 소스에게 특정 메시지를 보내야 하는데, 멀티캐스트 그룹 또는 호스트에 직접 메시지를 전송한다. 장점은 멀티캐스트 트리를 사용하기 때문에 다른 호스트들은 계속 동작이 가능하다.
소스가 특정기간 동안 재전송 요구를 감지 못할 경우, 수신자들과의 절단인지, 경청(listening)하는 수신자들가 더 이상 없는지를 확인해야 한다. 따라서 소스는 수신자들에게 상태요청을 전송한다. 수신자들 중 하나는 그 상태요청에 대한 응답을 실시하며, 그 응답을 멀티캐스트 어드레스상의 전 그룹에게 멀티캐스트하면, 다른 수신자들은 자신들의 응답을 취소한다. 소스는 그 상태요청 응답을 한번 수신하면, 적어도 하나의 수신자가 존재하여 데이터를 계속 수신한다는 것을 알수있다. 소스가 아무런 응답도 듣지 못한 경우, 수신자의 응답을 분실했거나, 그룹에 수신자가 없다고 가정한다.
메시지의 분실 가능성을 제거하기 위해 소스는 그룹에 수신자가 없다고 결론을 내리기 전에 이러한 상태요구(status request)를 몇번 반복해야 한다.
소스가 사이트의 동작실패(site failure)로부터 회복하는 경우, 소스는 새로운 시퀀스 넘버, 수신자는 낡은 시퀀스 넘버를 갖게되어 재동기가 필요하다. 소스가 새로운 시퀀스 넘버를 가진 새로운 스타트(START) 메시지를 보내면, 수신자는 새로운 스타트(START) 메시지를 받아 강제로 재동기를 실시한다. 소스는 데이터 전송시에 스타트(START)를 3번 반복하여, 전체의 수신자가 스타트(START)를 수신하도록 한다. 수신자들는 헤더(header)의 스타트(START) 메시지를 살피고, 스타트(START) 메시지를 손실할 때에는 에러가 발생하였음을 소스에게 NACK으로 알린다.
2. 에러수정 방식
전송 프로토콜은 신뢰성 보장을 위해 데이터 전송중에 발생하는 에러를 검출하고 수정한다. 이는 각 참가자에게 신뢰성있는 데이터 배달을 보장하며, 각 수신자는 각자 자신이 데이터의 분실, 파손에 대한 것을 예측하고 책임진다.
소스는 수신자로부터 아무것도 듣지 못하면 수신자의 데이터 수신에 이상이 없다고 판단한다. 수신자의 연결 단절시에는 소스가 재전송 방법이 있어도 에러수정을 위한 아무런 조치를 취할수 없다. 이에 대한 대책은 수신자가 그룹에 연결(connectivity)을 재설정하여 데이터를 재전송하여야 한다. 소스는 수신자의 손실 데이터 요청시에만 손실 데이터를 인식하기 때문에 에러검출은 수신자가 전적으로 책임을 담당한다.
수신자는 메시지에서 하나 또는 그 이상의 파손된 데이터를 발견, 확인하면 필요한 데이터에 대한 재전송을 요청할 수 있으며 여기에는 NACK을 사용한다. NACK은 IP-멀티캐스트(Multicast) 그룹을 통해 송신하며, 다른 호스트는 그 요청을 보고 댐핑(damping) 기술을 이용, 동일한 요청에 대한 전송을 예방한다.
소스가 재전송을 할 수 없는 경우에는 다른 호스트가 데이터를 재전송 하도록 한다. 재전송이 가능한 호스트는 재전송 처리를 실시할수 있도록 데이터용 버퍼가 충분해야 한다.
소스는 데이터 재전송 요구를 만족할 수 있는 커다란 버퍼를 갖으며, 데이터는 일단 폐기되면 버퍼에서 제거한다. 그리고 새로운 데이터용 버퍼로 사용하기 때문에 더 보관할 수 없다. 이러한 구조는 버퍼관리가 결정되지 않았기 때문에 일예로 사용하는 모델이다.
댐핑(damping) 기술의 사용은 많은 수신자가 동시에 응답함으로서 발생하는 메시지 폭주 가능성을 감소시키고, 폭주를 줄이기 위해 수신자는 손실 데이터 검출시 즉시 NACK를 송신하고, 다른 수신자들은 NACK을 경청(listen)한다. 수신자가 NACK을 감지한 경우는(재전송 요구) 자신의 NACK을 보낼 필요가 없다. 그러나, 다른 NACK을 받지 못했거나, 손실 데이터 보완이 충분하지 못하면, 그 로컬 수신자는 자신이 NACK을 송신할 필요가 있다. 모든 수신자가 동일한 기간동안 기다리게 되면 댐핑(damping) 기술은 무의미하다. 수신자들이 기다리는 시간간격은 일반적으로 제각기 다르다. 각 수신자는 재전송 요구 수행전에 경청(listen)을 위한 랜덤 타임값을 계산한다. 댐핑(damping) 기술의 이점은 반복을 줄이고, 소스와 네트워크의 패킷 포화를 제한한다.
데이터 전송 처리시 데이터의 부분적인 분실, 파손이 발생하게 된다. 수신자는 이들에 대한 재전송을 요구하며, 소스 또는 대리 호스트(peer-hosts)중 하나가 이를 재전송한다. 소스가 일정시간 동안 데이터를 송신하지 않을때는, 하트비트 메시지를 대신 송신한다.
데이터 재전송시의 2가지 모델은 소스가 재전송에 대한 책임을 담당하는 방법과 모든 호스트가 재전송에 대한 책임을 담당하는 방법이 있다. 전자는 데이터의 모든 재전송에 대해 응답하고, 어떤 이유에서 소스가 재전송할 수 없으면, 대리 호스트(peer-hosts)가 재전송에 대한 책임을 지게 되는 방법이다.
후자는 호스트들이 소스를 경청(listening : 소스 자신을 포함)하여 재전송에 대한 책임을 지게 되는 방법이다.
과도한 재전송 응답은 두가지의 해결 방안이 있다.
첫 번째 방법은 소스 자신이 실시하는 것으로, 단순하지만 호스트는 재전송 요구에 대한 책임을 지며 대리 호스트(peer host)는 응답하지 않는다. 그러나, 이 방법은 선택적으로 사용하여야 한다. 예를들면, 소스 호스트가 다른 일들로 과부하이면 제시간내에 재전송 배달이 불가능하기 때문에 선택적으로 사용하여야 한다.
두 번째 방법은 소스의 대리인이 실시하는 것으로, 이 방법은 재전송 처리가 늦고, 소스가 연결(connectivity) 문제를 내포하고 있는 경우에는, 대리 호스트(peer-hosts)의 재전송 응답이 지연된다. 모든 호스트가 잠재적인 재전송 포인트를 갖는 경우의 장점은 소스의 과부하 감소 처리가 가능하다. 이 방법은 빠른 응답이 가능한 다른 호스트(응답을 취급하는)에게 효율을 줄 수 있다. 과부하에 걸린 다른 호스트는 방법이 없다. 호스트가 수행하는 재전송은 소스가 호스트보다 더 과부하 상태인 경우이다.
소스 우선적인 모델을 사용하는 경우, 소스의 재전송 여력이 못 미치는 경우에도 재전송에 대한 요구는 만족된다. 오버헤드 때문에 소스 대신 다른 호스트가 재전송을 대신하는 경우, 우선 이 호스트는 이 기능을 수행하기 위해 소스 데이터의 수신자가 되어야 하며, 이 호스트는 소스 호스트로서 같은 방법으로 재전송 요구에 응답할 수 있다.
소스는 그 데이터의 재전송에 대한 응답을 피할 수 없기 때문에 일단 재전송에 대한 응답을 한다. 소스가 재전송 요구에 응답할 수 없는 경우에는 대리 호스트가 실시한다. 경우에 따라서는 재전송 취급에 대리 호스트가 소스보다 좋게 해결할 수 있으며, 대리 재전송 요구에 응답할 충분한 시간을 결정할 수 있다. 이는 타이머 또는 재전송 요구에 특정넘버를 이용하여 수행할 수 있다.
대리 호스트(peer-hosts)가 요청된 데이터를 재전송한 후에도 많은 요청 응답을 대리 호스트(peer-hosts)가 막을 수 있는 방법은 댐핑 기술을 사용하여 해결할 수 있다. 재전송 요구 응답을 기도하는 모든 대리 호스트(peer-hosts)는 다른 호스트로 부터의 요청에 응답하기 위해 경청(listening)하는 일정시간 동안을 기다린다.
특수한 상황으로 소스 또는 수신자가 절차외의 방법을 사용하는 경우로는, 수신자가 10번 시도 후에도 재전송을 받지 못하고, 그 기간동안 소스로부터 하트비트도 듣지 못하면, 수신자는 소스 호스트가 더 이상 가용하지 않다고 판단, 즉, 소스가 그룹에서 이미 탈퇴(leave)한 것으로 간주한다. 그룹을 탈퇴(leave)하는 소스의 상태를 수신자가 모르거나, 소스와의 연결이 손실된 두가지 경우 모두, 재전송 요구를 만족하는 대리 수신자가 없거나 피어 수신자들에도 원하는 데이터가 없는 경우이다. 이때는 전송 프로토콜은 응용계층에게 에러 발생을 통지한다. 응용계층은 이를 보고 응용계층의 상황에 맞추어 다음 행동을 결정한다. 수신자는 소스의 탈퇴를 주목하지 않는다. 즉, 수신자는 소스로 부터 규칙적으로 데이터나 하트비트를 수신하도록 되어있다.
특정시간 동안 소스로부터 어떤 메시지도 받지 못하는 경우, 수신자는 소스의 상태를 결정한다. 이는 중요한 사항으로, 수신자는 소스로부터 마지막 경청한 순간 개선(up-to-date)하기 때문이다. 그 시점에서 소스가 다른 데이터의 전송여부는 알 수 없다.
소스의 상태는 수신자가 명확한 요청(explicit request)을 통해 얻는다. 소스가 여전히 멀티캐스트 그룹내에 있으나 수신자이면, 전번 소스 호스트는 더 이상 소스가 아님을 알린다.
과거의 소스는 데이터의 마지막 세그먼트를 더 이상 보유할 수 없고, 마지막 패킷의 시퀀스 넘버를 명시하여 소스에게 전송한다. 수신자는 이것으로 손실된 데이터 유무를 결정한다. 수신자가 응용 계층에게 통지하면, 소스 천이에 의한 처리는 소스의 데이터가 더 이상 유효하지 않을때 완료되고, 데이터가 모든 수신자들에게서 폐기된다.
소스가 더 이상 멀티캐스트 그룹이 아닌 경우(탈퇴시)에는, 수신자들(status requester)은 대리 호스트에게 응답, 이는 대리 호스트들이 아직도 소스에 관한 정보를 보유하였다고 판단한다.
소스의 데이터와 하트비트 메시지를 가진 수신자는 재전송 종료 요청을 하지 못한다. 이는 소스로의 경로가 자신에게로 리턴된 네트워크 에러 때문이다. 이 경우, 대리 수신자는 소스 입장에서 재전송을 수행할 수 있다. 재전송 요청을 경청(listening)하는 대리 수신자가 없다면, 수신자는 에러상태를 종료하고 이를 응용 계층에게 통보한다.
본 발명에 따른 에러제어 방법은 기존 전송 프로토콜의 송신자가 수신자에게 연결을 요청(connection request)하고 수신자는 이를 지시(connection indication)받아 송신자에게 응답(connection response)하는 단계적인 3-웨이 핸드쉐이크(3-way handshake) 방식과는 달리, 소스와 다수의 수신자들이 사전에 정해진 규약에 따라 세션에 참여하는 방법으로 IP-멀티캐스트(multicast)상에서 수신자들이 경청(listening) 상태에 대기중인 수신자들에게 소스의 출발(START) 메시지 송신을 연결 설정의 첫단계로 수신자들이 이를 수신하는 동작에 의한 묵시적 연결방식(soft connection)에서 상호간의 상태천이를 유지하고, 궁극적으로는 이들간의 송수신 과정에서 발생하는 에러들을 검출, 보고, 수정 과정을 통하여 메시지를 신뢰성있게 전달되도록 하고 있다.
이하, 첨부된 도면을 참조하여 본 발명을 상세히 설명하기로 한다.
도 1은 본 발명이 적용되는 전송 프로토콜의 내부 상태흐름도로서, 송수신자들간의 연결, 탈퇴, 에러제어, 데이터 전송을 위한 상태의 변환을 기술하기 위해 도시한 것이다.
닫기(CLOSED) 상태(104)는 모든 소스와 수신자들이 응용 계층으로부터 통신을 시작하기 전단계이다.
송신(SENDING) 상태(101)는 소스가 응용 계층으로부터 소스 오픈 명령을 수신하면 수신자들에게 스타트(START) 패킷을 전송한 후 실질적인 데이터를 전송하는 상태이다.
대기 1(WAIT_1) 상태(105)는 송신 상태(101) 또는 수신(RECEIVING) 상태(109)의 소스와 수신자가 에러 요청에 응답하는 상태이다. 에러 메시지를 수신할 때 소스 또는 수신자등의 호스트는 대기 1 상태(105)로 들어가서 에러 메시지에 응답하고 복구된 수정 데이터를 제공한다. 대기 1 상태(105)는 대리 호스트가 에러 메시지를 응답하기 위한 댐핑에 사용한다. 호스트는 수정 데이터를 발생하고, 타이머를 가동한 다음, 다른 대리 호스트가 수정 데이터에 응답하는가 확인하면서 기다리는 타이머 기간 끝에 아무도 전송하지 않으면, 호스트는 송신 복구(SEND_REPAIR) 상태(106)로 이동한 후, 멀티캐스트 그룹에 수정 데이터를 송신한다. 그러나, 다른 대리 호스트가 수정 데이터를 응답하는 경우에는 원래의 송신 상태(101) 또는 수신 상태(109)로 되돌아 온다.
대기 2(WAIT_2) 상태(110)에서 수신자는 패킷의 첵섬값을 검사하여 패킷 파손을 검출하고, 패킷 시퀀스 넘버를 추적하여 분실된 패킷을 검출하며 일단 데이터가 전송되었지만 수신하지 못하였다는 사실을 알게되면 타이머를 호출한다. 타이머 종료 후 수신자는 대기 2 상태(110)로 이동한다. 이 상태에서 수신자는 에러를 검출하여 멀티캐스트 그룹에게 NACK를 보낸다. NACK의 수를 줄이는 댐핑(damping)을 위해 수신자가 이 상태에서 대기하면, 멀티캐스트 그룹내의 다른 호스트가 NACKs를 경청(listen)한다. 대기 2 상태(110)에서 타이머가 소멸되면, 수신자는 에러 메시지를 발생하여 멀티캐스트 그룹에 보내고 대기 3(WAIT_3) 상태(111)로 이동한다. 다른 호스트(소스 또는 다른 수신자)로부터 에러 메시지에 대한 응답이 없으면, 수신자는 대기 2 상태(110)로 되돌아가며 에러 메시지를 다시 발생한다. 대기 2 상태(110)와 대기 3 상태(111)간의 이러한 진퇴(back-and-forth) 천이는 오직 5번만 실시한다. 호스트는 5번의 타이머가 종료된 후에도 진전이 없으면, 소스와 수신자간의 연결 설정에 이상이 발생한 것으로 가정하고 응용 계층에 에러가 발생하였음을 통보한다.
대기 2 상태(110)의 수신자는 다른 호스트가 에러를 검출하면, 대기 3 상태(111)로 이동하여 에러 메시지의 응답을 기다리고, 수정 데이터를 수신할 때 정상적인 수신 상태(109)로 이동한다.
송신 복구(SEND_REPAIR) 상태(106)에서 수신자가 소스로부터 수신한 데이터 패킷에 오류가 있을 경우 또는 데이터 패킷을 수신하지 못한 경우에 소스는 자신의 버퍼에 저장한 데이터에서 해당 시퀀스 넘버(Sequence Number)를 가진 데이터를 찾아 데이터 패킷에 부착된 타이머가 소멸하기 전에 수신자에게 해당되는 데이터 패킷을 재전송하여 데이터 패킷을 복구한다.
종료(CLOSING) 상태(103)는 소스가 송신 상태(101)에서 하트비트(HEARTBEATS) 상태(102)로 천이하여 주어진 시간이 경과하면 타이머에 의해 6번의 하트비트(Heartbeat) 메시지를 수신자에게 송신하고 자신이 더 이상 데이터 패킷을 전송하지 않는다는 의사를 수신자에게 통보한 후 수신자의 위치로 변경하거나 통신을 종료하는 상태로 변경한다.
하트비트(HEARTBEATS) 상태(103)는 소스가 데이터 패킷을 전송한 후, 응용 계층의 상태에 따라 데이터 전송을 잠시 중단하는 유휴(idle) 상태에서 소스의 상태를 수신자들에게 알리는 방법으로 데이터 대신 하트비트를 보내는 상태이다.
수신 상태(109)는 수신자가 응용 계층으로부터 수신자 오픈 명령을 접수하여 경청(LISTEN) 상태(107)로 천이한 후, 소스로부터 본격적으로 데이터 패킷을 수신하는 상태이다.
경청 상태(107)는 수신자가 응용 계층으로부터 수신자 오픈 명령어를 접수하면, 수신자측의 전송 프로토콜은 소스로 부터의 스타트(Start) 패킷을 수신할 준비를 하는 상태이다.
시작 실패(START MISSED) 상태(108)는 경청 상태(107)에서 수신자가 소스가 보낸 스타트 패킷을 수신하지 못한 경우로서, 수신자는 이 상태에 따라 스타트 패킷을 받은 경우에는 정상적인 조인(Join) 상태, 받지 못한 경우에는 레이트 조인(Late Join) 상태로 처리된다.
도 2는 본 발명에 따른 에러 검출과 재전송 요청을 위한 상태 처리도이다. 수신(RECEIVING) 상태(21)에서 수신자는 시퀀스 넘버를 추적하여 메시지 배달 과정에서 발생한 에러를 검출하고, 복구 기간에 필요한 타이머를 호출한다. 여기서, 검출 대상은 수신 데이터이다.
타이머 종료후에 수신자는 대기 2(WAIT_2) 상태(22)로 이동한다. 이 상태에서 수신자는 에러를 검출하고 멀티캐스트 그룹에게 NACK를 보낸다. NACK의 수를 줄이는 댐핑(damping)을 위해 수신자가 이 상태에서 대기하면, 멀티캐스트 그룹내의 다른 호스트는 NACKs를 경청(listen)한다.
수신자는 다른 호스트가 이미 에러를 검출하였다면, 대기 3(WAIT_3) 상태(23)로 이동하여 에러 메시지에 대한 응답을 기다리고, 수정 데이터를 수신할 경우에는 정상적인 수신 상태(21)로 이동한다.
대기 2 상태(22)에서 타이머가 소멸되면, 수신자는 에러 메시지를 발생하여 멀티캐스트 그룹에 보내고 대기 3 상태(23)로 이동한다. 다른 호스트(소스 또는 다른 수신자)로부터 에러 메시지에 대한 응답이 없으면, 수신자는 대기 2 상태(22)로 되돌아가며 에러 메시지를 다시 발생한다. 대기 2 상태(22)와 대기 3 상태(23)간의 이러한 진퇴(back-and-forth) 천이는 오직 10번만 실시한다. 호스트는 10번의 타이머가 종료된 후에도 진전이 없으면, 소스와 수신자간의 연결 설정에 심각한 장애가 발생한 것으로 판단하고 에러 콘디션을 응용 계층에게 통지한다.
도 3은 본 발명에 따른 에러 수정을 위한 상태 천이도이다. 송신 상태(31) 또는 수신 상태(32)에 있는 호스트는 다른 대리 호스트를 통해 에러 요청에 응답한다. 에러 메시지를 수신할 경우 호스트는 대기 1 상태(33)로 들어가서 에러 메시지를 응답하고 올바른 수정 데이터를 제공한다. 대기 1 상태(33)는 대리 호스트가 에러 메시지를 응답하기 위한 댐핑에 사용한다. 호스트는 수정 데이터를 발생하고, 타이머를 가동한 후 다른 대리 호스트가 수정 데이터에 응답하는가 기다리는 타이머 기간이 끝나면 송신 복구 상태(34)로 이동하고 멀티캐스트 그룹에 수정 데이터를 송신한다. 그러나, 다른 대리 호스트가 수정 데이터를 응답한 경우에는 호스트는 원래의 송신 상태(31) 또는 수신 상태(32)로 되돌아 온다.
하트비트 메시지는 소스 호스트의 존재와 상태 표시에 사용한다. 최초로 보내는 하트비트 메시지는 소스 호스트만이 전송하며, 마지막 패킷의 시퀀스 넘버에 포함된다.
하트비트는 응용 계층에서 회의중의 잠시 의견교환 중단 또는 소스가 데이터를 전송하지 않는 유휴(idle) 상태에서 발생하며, 현재 소스가 데이터를 전송하지 않고 있다는 의도를 수신자가 인식하게 하고, 소스의 정지 시간, 활동 상태등을 나타낸다. 소스가 일정 기간동안 전송을 중지할 때는 정상으로 전송될 때까지 하트비트를 규칙적으로 발송한다. 소스가 데이터 전송을 하지않는 경우 일정한 기간이 경과한 후 NACK의 양, 흐름제어(flow control) 파라미터, 상수등의 왕복 배달에 걸리는 시간을 계산한다.
수신자도 소스에게 주기적으로 하트비트 메시지를 송신하여 수신자가 수신한 마지막 메시지(FINAL)를 알리도록 한다. 수신자가 보내는 하트비트 정보는 소스만이 요구할 수 있고 다른 수신자는 할 수 없으며, 수신자는 소스에게 하트비트를 유니캐스트(Unicast)로 전송한다. 이 하트비트에는 수신자 ID와 콘넥션의 포트(port) 넘버를 포함하며, 수신자가 수신한 마지막 메시지의 시퀀스 넘버도 포함한다. 소스는 여러 수신자에게서 오는 하트비트 폭주를 피하기 위한 방법으로 주기적으로 하나의 수신자를 선택하는 무작위(Randomized) 방법을 사용한다.
도 4는 전송 프로토콜이 시스템 내부에 탑재된 상태를 나타낸 것으로, 전송 프로토콜이 들어있는 상태 처리기내의 흐름제어(Flow Control)를 담당하는 부분을 나타내고 있다.
도시된 바와 같이 전송 프로토콜(401)이 중심에 위치하고, 상위측에는 응용 인터페이스(Application Interface: 이하 API라 함)(402)와 연결되고, 하위측에는 커널(403)을 통해 네트워크(404)와 연결된다.
응용계층은 API(402)와 통신하기 위해 공용 버퍼(shared buffer)(405)를 사용하여 큐 리스트(Queue List)를 구성하고, 구성된 큐 리스트를 프로토콜(401)의 큐(406)로 전송한다. 프로토콜에서는 상태 처리기에 의한 통신 절차를 수행하고 포맷(Format) 수단(407)에서 전송할 데이터 패킷을 포맷하여 전송 프로토콜 시스템 인터페이스(TP System Interface)(408)로 보낸다. 전송 프로토콜 시스템 인터페이스(408)의 포맷화된 데이터 패킷은 커널(403)을 통해 네트워크(404)로 전송된다. 네트워크(404)로 전송된 포맷화된 데이터 패킷은 여러 수신자들에게 전송된다. 수신자측에서는 이들 포맷화된 데이터 패킷을 분해(Paese) 수단(409)에서 분해한 후 상위의 전송 프로토콜로 올려 보내면 프로토콜 내부에서는 연결 관리 수단(Connection management)(400), 흐름제어 수단(Flow Control)(411), 에러제어 수단(Error Control)(412), 타이머(Timers)(414), 버퍼 관리 수단(Buffer Management) (415)등 상태처리에 따르는 절차를 수행한 후에 큐 리스트(Queue List)를 만들어 큐(406)를 통해 응용계층으로 전달되는 구조로 구성되어 있다. 연결 관리 수단(Connection management)(410), 흐름제어 수단(Flow Control)(411), 에러제어 수단(Error Control)(412)은 유한 상태 장치(Finite State Machine; FSM)(413)를 구성한다.
연결 설정을 하기 위한 전 단계의 절차로서 시스템 내부에서는 단계적으로 응용 계층에서 프로토콜 내부로 이어지는 순서인 API를 3가지 절차로 수행한다.
프로토콜의 초기화는 응용 계층으로부터 멀티캐스트 어드레스와 포트 넘버를 가져와서 프로토콜을 시동한다. 또한 응용 계층은 소스를 확인하기 위한 단일(unique) ID를 제공한다. 읽기와 쓰기의 순서는 데이터를 교환하기 위해 응용 계층과 API간에 공용 버퍼(shared buffer)를 사용한다. API 쓰기 절차는 응용계층 버퍼로부터 전송 프로토콜의 버퍼로 데이터를 복사한다. 흐름제어 방식은 타이머 및 버퍼링과 많은 연관 관계를 갖는다.
도 5는 본 발명에 따른 에러 검출과 재전송 요청에 대한 처리 흐름도로서, 도 1 내지 도 3의 부분적인 설명들을 종합한 것이다.
수신자는 소스로부터 데이터와 하트비트를 수신하고(51), 데이터 및 하트비트를 분석하여(52) 데이터 접수에서 에러가 발생하였는지를 결정한다(53). 데이터 접수에서 에러가 발생했을 경우 소스로부터 데이터와 하트비트를 재수신하고, 에러가 발생하지 않았을 경우 시퀀스 넘버 영역밖의 데이터 패킷을 수신하였는지를 검사한다(54). 시퀀스 넘버 영역내의 데이터 패킷을 수신하였을 경우 수신한 데이터와 하트비트를 분석하는 단계(52)로 천이한다. 수신자가 시퀀스 영역 밖의 데이터 패킷을 수신하였을 경우 에러를 가리키기 위한 에러 수정 메카니즘을 구동한다(55). 수신자가 소스로부터 재전송 요청을 위한 문턱값(threshold) 이내에 어떠한 메시지라도 수신할 경우(56), 수신한 데이터와 하트비트를 분석하는 단계(52)로 천이하고, 아무것도 수신하지 못하였을 경우(56), 수신자는 멀티캐스트 그룹에 쿼리(query) 메시지를 보내어 소스의 상태에 대해 문의한다(57). 소스는 하트비트를 전송하여 상태에 대한 쿼리(query)에 즉시 응답한다(58). 그리고, 소스로부터 수신되는 데이터 패킷에 에러가 있을 경우(59), 단계 (51)로 천이하고, 더 이상 데이터 패킷에 에러가 없을 경우 종료한다.
도 6은 본 발명에 따른 에러수정에 대한 처리 흐름도로서, 도 5의 단계 (55)를 상세하게 설명하기 위한 것이다.
현재 구현된 프로토콜은 오직 소스만이 재전송에 대한 응답을 하도록 되어있다. 소스는 데이터 패킷을 전송할 때 재전송을 위해 자신의 버퍼에 패킷을 저장한다(61). 데이터를 폐기한 후 버퍼 관리자는 이 버퍼로부터 데이터를 폐기한다.
수신자로부터 재전송 요구가 있었는가를 검사하여(62) 재전송 요구가 있을 경우 수신자로 부터의 재전송 요구 패킷에 대한 왕복 지연 시간(Round Trip Delay : 이하 RTD라 함)을 소스가 판정하고, 수신자들의 요구에 대한 최적의 응답을 계산하기 위해 분석한다(63). 단계 (62)의 검사 결과 재전송 요구가 없을 경우 단계 (69)로 잔행한다. 데이터를 재전송할 것인지를 판단하여(64) 데이터를 재전송하게 되면 소스는 버퍼로부터 데이터 패킷을 회수하고 이를 재전송한다(65). 에러수정 방법은 go-back-N 방식이다. 그러므로, 모든 부수적인 데이터 패킷들은 버퍼로부터 회수되어 재전송된다. 단계 (64) 결과 데이터를 재전송하지 않으면 소스가 수신자의 재전송 요구를 만족시키지 못하는지를 검사한다(66). 만약 소스가 수신자들의 재전송 요구를 만족하지 못하면, 소스는 멀티캐스트 어드레스상에 가장 오래된(oldest) 데이터 패킷의 시퀀스 넘버와 함께 에러 메시지를 전송한다(67).
단계 (65), 단계 (66)의 재전송 요그를 만족할 경우, 그리고 단계 (67)을 수행한 후 수신자는 재전송을 사용하여 소스로부터 수정 데이터를 수신하였는지를 검사한다(68). 소스로부터 수정 데이터를 수신하지 않았을 경우 단계 (66)으로 천이하고, 소스로부터 수정 데이터를 수신할 경우 소스로부터 수신된 데이터 패킷에 에러가 없는지를 검사한다(69). 데이터 패킷에 에러가 있을 경우 단계 (62)로 천이하고, 에러가 없을 경우 종료한다.
이상에서 설명한 바와 같이 본 발명은 멀티미디어 데이터를 다지점과 다자간에 신뢰성이 높게 전송하기 위한 에러제어 방법으로 여러 응용 분야에 접속하여 사용할 수 있다.
상술한 바와 같이 본 발명에 의한 알고리즘은 컴퓨터 통신의 전송 프로토콜에 사용하여 다자간에 신뢰성있는 멀티미디어 데이터 전송을 가능하게 할 뿐만 아니라 데이터의 손실을 최소화할 수 있다.
Claims (2)
- 소스로부터 데이터와 하트비트를 수신한 수신자가 상기 데이터 및 하트비트를 분석하여 데이터 접수에서 에러가 발생하였는지를 검사하는 제 1 단계와,상기 제 1 단계의 검사 결과 데이터 접수에서 에러가 발생했을 경우 소스로부터 데이터와 하트비트를 재수신하고, 에러가 발생하지 않았을 경우 시퀀스 넘버 영역밖의 데이터 패킷을 수신하였는지를 검사하는 제 2 단계와,상기 제 2 단계의 검사 결과 시퀀스 넘버 영역내의 데이터 패킷을 수신하였을 경우 수신한 데이터와 하트비트를 분석하는 단계로 천이하고, 수신자가 시퀀스 영역 밖의 데이터 패킷을 수신하였을 경우 에러 수정 메카니즘을 구동하는 제 3 단계와,상기 에러 수정 메카니즘을 구동한 후 수신자가 소스로부터 재전송 요청을 위한 문턱값 이내에 어떠한 메시지라도 수신할 경우 수신한 데이터와 하트비트를 분석하는 단계로 천이하고, 아무것도 수신하지 못하였을 경우 수신자가 멀티캐스트 그룹에 쿼리 메시지를 전송하여 소스의 상태에 대해 문의하는 제 4 단계와,상기 쿼리에 대한 응답으로 소스가 하트비트를 전송하고, 소스로부터 수신되는 데이터 패킷에 에러가 있을 경우 소스로부터 데이터 및 하트비트를 수신하는 단계로 천이하고, 더 이상 데이터 패킷에 에러가 없을 경우 종료하는 제 5 단계를 포함하여 이루어진 것을 특징으로 하는 다자간 멀티미디어 통신에서의 에러제어 방법.
- 제 1 항에 있어서, 상기 제 3 단계의 에러 제어 메카니즘은 데이터 패킷을 저장할 때 자신의 버퍼에 상기 데이터 패킷을 저장한 소스가 수신자로부터 재전송 요구가 있었는가를 검사하는 단계와,상기 재전송 요구가 있었는지의 검사 결과 상기 수신자로부터 재전송 요구가 있을 경우 수신자로 부터의 재전송 요구 패킷에 대한 왕복 지연 시간을 판정하고, 최적의 응답을 계산한 후 데이터를 재전송할 것인지 판단하는 단계와,상기 데이터를 재전송할 것인지의 판단 결과 데이터를 재전송할 것을 판단한 소스가 버퍼로부터 데이터 패킷을 회수하고 재전송하는 단계와,상기 데이터를 재전송할 것인지의 팥단 결과 데이터를 재전송하지 않을 것을 판단한 소스가 수신자의 재전송 요구를 만족시키지를 검사하는 단계와,상기 재전송 요구를 만족시키는지의 검사 결과 소스가 수신자들의 재전송 요구를 만족하지 못하면, 멀티캐스트 어드레스상에 가장 오래된 데이터 패킷의 시퀀스 넘버와 함께 에러 메시지를 전송하는 단계와,상기 소스가 데이터 패킷을 회수하고 재전송한 후, 상기 소스가 수신자들의 재전송 요구를 만족하는 경우, 그리고 상기 에러 메시지를 전송한 후 수신자가 소스로부터 수정 데이터를 수신하였는지를 검사하는 단계와,상기 수신자가 소스로부터 수정된 데이터를 수신하였는지의 검사 결과 소스로부터 수정 데이터를 수신하지 않았을 경우 상기 소스가 수신자의 재전송 요구를 만족시키는지를 검사하는 단계로 천이하는 단계와,상기 수신자가 소스로부터 수정된 데이터를 수신하였는지의 검사 결과 소스로부터 수정 데이터를 수신할 경우 소스로부터 수신된 데이터 패킷에 에러가 없는지를 검사하여 데이터 패킷에 에러가 있을 경우 수신자로부터 재전송 요구가 있는지를 검사하는 단계로 천이하고, 에러가 없을 경우 종료하는 단계를 포함하여 이루어진 것을 특징으로 하는 다자간 멀티미디어 통신에서의 에러제어 방법.
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| KR1019970051198A KR100248080B1 (ko) | 1997-10-06 | 1997-10-06 | 다자간 멀티미디어 통신에서의 에러제어 방법 |
| US09/145,736 US6141785A (en) | 1997-10-06 | 1998-09-02 | Error control method for multiparty multimedia communications |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| KR1019970051198A KR100248080B1 (ko) | 1997-10-06 | 1997-10-06 | 다자간 멀티미디어 통신에서의 에러제어 방법 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| KR19990030782A KR19990030782A (ko) | 1999-05-06 |
| KR100248080B1 true KR100248080B1 (ko) | 2000-03-15 |
Family
ID=19522263
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| KR1019970051198A KR100248080B1 (ko) | 1997-10-06 | 1997-10-06 | 다자간 멀티미디어 통신에서의 에러제어 방법 |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US6141785A (ko) |
| KR (1) | KR100248080B1 (ko) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR101405533B1 (ko) | 2010-12-15 | 2014-06-11 | 한국전자통신연구원 | 고가용성 멀티캐스트 전송 기반의 메시지 전송 시스템 |
Families Citing this family (31)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6718376B1 (en) * | 1998-12-15 | 2004-04-06 | Cisco Technology, Inc. | Managing recovery of service components and notification of service errors and failures |
| US7370102B1 (en) | 1998-12-15 | 2008-05-06 | Cisco Technology, Inc. | Managing recovery of service components and notification of service errors and failures |
| US6357028B1 (en) * | 1999-03-19 | 2002-03-12 | Picturetel Corporation | Error correction and concealment during data transmission |
| US6487689B1 (en) * | 1999-07-08 | 2002-11-26 | Lucent Technologies Inc. | Receiver initiated recovery algorithm (RIRA) for the layer 2 tunneling protocol (L2TP) |
| JP3618600B2 (ja) * | 1999-09-28 | 2005-02-09 | 株式会社東芝 | 無線通信システム、無線通信方法、無線基地局、および無線端末局 |
| US6608818B1 (en) * | 1999-11-10 | 2003-08-19 | Qualcomm Incorporated | Radio link protocol enhancements to reduce setup time for data calls |
| US6704782B1 (en) * | 1999-12-09 | 2004-03-09 | International Business Machines Corporation | System and methods for real time progress monitoring in a computer network |
| SE0000897D0 (sv) * | 2000-03-17 | 2000-03-17 | Ericsson Telefon Ab L M | Methods in a communication system |
| US7284064B1 (en) | 2000-03-21 | 2007-10-16 | Intel Corporation | Method and apparatus to determine broadcast content and scheduling in a broadcast system |
| US7017075B1 (en) * | 2000-05-12 | 2006-03-21 | Intel Corporation | Recovering from video driver errors |
| US6965916B1 (en) * | 2000-12-14 | 2005-11-15 | Bellsouth Intellectual Property Corp. | System and method for data distribution and recovery |
| US7363569B2 (en) * | 2001-06-29 | 2008-04-22 | Intel Corporation | Correcting for data losses with feedback and response |
| US8943540B2 (en) | 2001-09-28 | 2015-01-27 | Intel Corporation | Method and apparatus to provide a personalized channel |
| EP1508991A1 (en) * | 2002-05-29 | 2005-02-23 | Mitsubishi Denki Kabushiki Kaisha | Data error control method |
| KR100495344B1 (ko) * | 2002-07-31 | 2005-06-14 | 주식회사 케이티프리텔 | 명시적 멀티캐스트의 수신성 시험과 도달성 시험을 위한방법 및 장치 |
| KR100711635B1 (ko) * | 2003-02-18 | 2007-04-25 | 노키아 코포레이션 | 화상 부호화 방법 |
| EP1595404B1 (en) | 2003-02-18 | 2014-10-22 | Nokia Corporation | Picture decoding method |
| US20040236829A1 (en) * | 2003-05-13 | 2004-11-25 | Yikang Xu | Reliable delivery of multi-cast conferencing data |
| US7181637B2 (en) * | 2003-12-02 | 2007-02-20 | International Business Machines Corporation | Packet processing system and method for a data transfer node with time-limited packet buffering in a central queue |
| US20050160345A1 (en) * | 2003-12-24 | 2005-07-21 | Rod Walsh | Apparatus, system, method and computer program product for reliable multicast transport of data packets |
| US20050201471A1 (en) * | 2004-02-13 | 2005-09-15 | Nokia Corporation | Picture decoding method |
| US7296205B2 (en) * | 2004-02-18 | 2007-11-13 | Nokia Corporation | Data repair |
| US7536622B2 (en) * | 2004-03-29 | 2009-05-19 | Nokia Corporation | Data repair enhancements for multicast/broadcast data distribution |
| US7684654B2 (en) * | 2004-06-30 | 2010-03-23 | General Electric Company | System and method for fault detection and recovery in a medical imaging system |
| US9124907B2 (en) * | 2004-10-04 | 2015-09-01 | Nokia Technologies Oy | Picture buffering method |
| US8274978B2 (en) * | 2007-01-17 | 2012-09-25 | Panasonic Corporation | Systems and methods for reducing multicast traffic over a network |
| US8055991B2 (en) * | 2007-12-12 | 2011-11-08 | International Business Machines Corporation | Error detection and recovery using an asynchronous transaction journal |
| JP5748471B2 (ja) * | 2010-12-14 | 2015-07-15 | キヤノン株式会社 | 配信装置、配信方法、プログラム |
| US9083623B2 (en) * | 2012-03-12 | 2015-07-14 | Texas Instruments Incorporated | Inserting source, sequence numbers into data stream from separate sources |
| JP6181859B2 (ja) * | 2013-05-30 | 2017-08-16 | チャング−アング ユニバーシティー−アカデミー コーポレーション ファンデーション | 無線ネットワークでマルチキャストグループを管理する装置及び方法 |
| CN108961737B (zh) * | 2018-06-28 | 2020-09-29 | 光大环保技术研究院（南京）有限公司 | 一种使用动态周期监测数据采集端异常的方法 |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4841526A (en) * | 1984-05-25 | 1989-06-20 | Wilson Jon C | Data communications system |
| US5664091A (en) * | 1995-08-31 | 1997-09-02 | Ncr Corporation | Method and system for a voiding unnecessary retransmissions using a selective rejection data link protocol |
-
1997
- 1997-10-06 KR KR1019970051198A patent/KR100248080B1/ko not_active IP Right Cessation
-
1998
- 1998-09-02 US US09/145,736 patent/US6141785A/en not_active Expired - Lifetime
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR101405533B1 (ko) | 2010-12-15 | 2014-06-11 | 한국전자통신연구원 | 고가용성 멀티캐스트 전송 기반의 메시지 전송 시스템 |
Also Published As
| Publication number | Publication date |
|---|---|
| KR19990030782A (ko) | 1999-05-06 |
| US6141785A (en) | 2000-10-31 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| KR100248080B1 (ko) | 다자간 멀티미디어 통신에서의 에러제어 방법 | |
| KR101032512B1 (ko) | 멀티캐스트 컨퍼런스 세션 참가 방법 및 컴퓨터 판독 가능 기록 매체 | |
| Obraczka | Multicast transport protocols: a survey and taxonomy | |
| US6507562B1 (en) | Dynamic optimization for receivers using distance between a repair head and a member station in a repair group for receivers having a closely knit topological arrangement to locate repair heads near the member stations which they serve in tree based repair in reliable multicast protocol | |
| US7970828B2 (en) | Liveness monitoring in a publish/subscribe messaging system | |
| Xu et al. | Resilient multicast support for continuous-media applications | |
| US6526022B1 (en) | Detecting congestion by comparing successive loss of packets in windows to provide congestion control in reliable multicast protocol | |
| US20030031175A1 (en) | Method of multicasting | |
| US6505253B1 (en) | Multiple ACK windows providing congestion control in reliable multicast protocol | |
| US20090006641A1 (en) | Reliable multicast transport protocol | |
| JPH05207023A (ja) | 大量データ伝送方法 | |
| Sabata et al. | Transport protocol for reliable multicast: TRM | |
| US20070263626A1 (en) | A System for Session-Oriented Reliable Multicast Transmission. | |
| JP2001308900A (ja) | グループマルチキャスティングのためのネットワークおよびプロトコル | |
| US20030137948A1 (en) | Retransmission control in wireless packet data networks | |
| US20030035407A1 (en) | Packet retransmission in wireless packet data networks | |
| KR100223014B1 (ko) | 다자간 통신에서의 에러 제어 방법 | |
| JP4626646B2 (ja) | パケット通信装置及びパケット通信方法及びパケット通信プログラム | |
| KR100240651B1 (ko) | 다자간 멀티미디어 통신에서 소스 및 수신자의 연결제어 방법 | |
| KR100204598B1 (ko) | 전송 프로토콜에서 다자간 통신의 에러 검출 및 에러 수정방법 | |
| KR100204587B1 (ko) | 전송 프로토콜의 소스및 수신자 연결 제어 방법 | |
| KR100248079B1 (ko) | 멀티미디어 통신에서의 버퍼관리 방법 | |
| Yoon et al. | Tree-based reliable multicast in combined fixed/mobile IP networks | |
| Mane | WAIT, Selective Loss Recovery for Multimedia Multicast | |
| Venkitaraman | A Protocol for Reliable SSM |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A201 | Request for examination | ||
| E701 | Decision to grant or registration of patent right | ||
| GRNT | Written decision to grant | ||
| FPAY | Annual fee payment |
Payment date: 20081202 Year of fee payment: 10 |
|
| LAPS | Lapse due to unpaid annual fee |