KR20070115944A - 핸드쉐이크리스 재송신 프로토콜 - Google Patents

Abstract

소정의 실시예에 따른 핸드쉐이크리스 통신(handshakeless communication)에서 사용하기 위한 재송신 방법은, 패킷 소스로부터 패킷 수신 디바이스로 패킷 시퀀스를 송신하는 단계 - 상기 패킷 시퀀스 내의 각 패킷은 그들과 관련된 시퀀스 번호를 갖고, 상기 송신 단계는 송신 버퍼로부터 다음 패킷을 검색하는 단계와 상기 다음 패킷을 송신하는 단계를 포함함 - ; 상기 패킷 수신 디바이스에서, 수신된 패킷들의 시퀀스 번호에서 갭이 존재하는지를 판별하여 패킷이 수신되지 않았는지를 판별하는 단계; 상기 수신 디바이스로부터 상기 송신 디바이스로 재송신 요청을 전달하는 단계 - 상기 재송신 요청은, 시퀀스 번호의 갭을 채우는 패킷의 특정 시퀀스의 재송신을 요청하는 것임 - ; 상기 패킷 소스에서, 상기 특정 패킷에 대한 상기 재송신 요청을 수신하는 단계; 상기 패킷 소스에서, 상기 특정 패킷이 상기 송신 버퍼에서 이용 가능한 상태인지를 판별하는 단계; 상기 특정 패킷이 상기 송신 버퍼에서 이용가능한 상태라면, 상기 특정 패킷을 상기 수신 디바이스로 재송신하는 단계; 및 상기 특정 패킷이 상기 송신 버퍼에서 이용가능한 상태가 아니라면, 상기 재송신 요청을 무시하는 단계를 수반한다. 그 외의 실시예들은 이 요약서에서 설명된 특징들에서 벗어날 수도 있으므로, 이 요약서는 한정하고자 한 것이 아니다.

핸드쉐이크리스, 재송신, 통신, 패킷, 시퀀스, 송신 버퍼, 수신 디바이스

Description

핸드쉐이크리스 재송신 프로토콜{HANDSHAKELESS RETRANSMISSION PROTOCOL}

통신 시스템은 대개 "확인 프로토콜(acknowledged protocol)"을 사용하여 데이터 패킷을 전송하는 데이터 채널을 포함한다. 확인 프로토콜의 일례로는 인터넷에서 사용되는 것으로서 TCP(transport control protocol)가 있다. 확인 프로토콜은 고신뢰의 지점 대 지점 데이터 전송을 제공하도록 설계되고 이로써 에러인 것으로 발견된 데이터 패킷을 재송신하는 방법을 제공한다. 대개 CRC 코드 등의 에러 제어 코드가 전달되어, 수신기로 하여금 수신된 데이터 패킷이 에러를 포함하는지 여부를 판정하도록 허용한다. 데이터 패킷이 에러를 포함한다면, 잘못된 패킷(errant packet)이 재전달될 수도 있는 송신기로 재시도-요청 패킷이 회송된다.

비-확인 프로토콜의 일례로는 역시 인터넷에서 사용되는 것으로서 UDP(user datagram protocol)가 있다. UDP 패킷이 전달되는 경우, 어떠한 확인도 요구되지 않는다. 오히려 방송 혹은 멀티캐스트 방법을 사용하여 UDP 패킷들이 네트워크를 통해 하나 이상의 수신처로 쏟아져 들어갈(flooded) 수 있다. 방송은 하나 이상의 패킷을 네트워크상의 모든 노드에 전달하는 단계를 수반한다. 멀티캐스트는 하나 이상의 패킷을 네트워크상의 하나 이상의 노드 - 반드시 모든 노드일 필요는 없음 - 에 전달하는 단계를 수반한다. TCP와 비교할 때, UDP 패킷 스트림은, 어떠한 확인 패킷 및 어떠한 재전달 패킷도 UDP 패킷 스트림과 관련되지 않기 때문에 대역폭 을 덜 소모한다. 실시간 멀티미디어 뷰어 및 플레이어 등의 소정의 데이터 유형들에 대해, 늦은 패킷(late packet)은, 마치 잘못된 패킷(erroneous packet)인 것처럼, 단순히 폐기된다. 따라서, 수취단(receiving end)에서 나중에만 폐기될 데이터는 재송신하지 않음으로써 네트워크 대역폭이 절약된다. 또한, UDP 패킷은 방송 및 멀티캐스트 데이터 전송 방법을 가능하게 한다. UDP 등의 비-확인 프로토콜의 사용 비용은 데이터의 신뢰도를 감소시킨다.

UDP 패킷은 대개 보증된(guaranteed) 대역폭 및 온-타임 전달을 갖는 데이터 전송을 제공하도록 설계된 프로토콜 내에서 사용된다. RSVP(resource reservation protocol)는 그 일례이다. RSVP는 보증된 대역폭 및 패킷 전달 시간으로 경로를 구축하기 위해 네트워크 라우터에 의해 사용된 프로토콜이다. 실시간 음성을 포함하는 멀티미디어 데이터 스트림을 보증하기 위해 RSVP 및 유사 프로토콜들이 필요로 되고 비디오 데이터는 특정 QOS와의 접속의 수취단에서 미디어 플레이어에 의해 재생될 수 있다.

RTP(Rea-time Transmission Protocol)는 지연 예측가능 및 지터 감소를 달성하기 위해 UDP 혹은 TCP에 걸쳐 사용되는 프로토콜이다. 그러나, RTP로는 패킷의 전달이 여전히 보증되지 않는다. 일반적으로, 보증된 패킷 전달을 달성하기 위해서는, 패킷의 수신이 확인되거나(ACK), 또는 패킷의 비수신이 확인되는(NACK) 핸드쉐이크 프로토콜(handshake protocol)이 요구된다. 패킷이 수신되지 않으면 재송신에 착수한다.

불행하게도, UDP 혹은 유사 프로토콜들을 사용하는 경우에, 그러한 핸드쉐이 킹 프로토콜의 오버레이 결과 대개 용인할 수 없는 지연이 발생하는데, 이는 UDP가 주로 시간에 민감한 패킷 전달(예컨대, 오디오 혹은 비디오 스트리밍)에 사용되기 때문이다.

목적 및 이점들과 함께, 구성 및 동작 방법을 설명하는 소정의 예시적인 실시예들은, 첨부 도면과 관련된 다음의 상세한 설명을 참조하여 가장 잘 이해될 수 있을 것이다.

도 1은 본 발명의 소정의 실시예들에 따른 예시적인 통신 시스템의 블록도이다.

도 2는 본 발명의 소정의 실시예들에 따른 수신기 프로세스의 플로우차트이다.

도 3은 본 발명의 소정의 실시예들에 따른 송신기 프로세스의 플로우차트이다.

도 4는 본 발명의 소정의 실시예들에 따른 버퍼의 도면이다.

도 5는 본 발명의 소정의 실시예들에 따른 수신 버퍼에 대한 바람직한 링크 리스트법(linked list method)의 동작을 설명하는 플로우차트이다.

본 발명은, 도면에 도시되고 여기서 특정 실시예로서 상세하게 설명되는 많은 다른 형태의 실시예들을 허용하지만, 그러한 실시예들로 이루어진 본 개시물은 원리의 일례로서 간주될 것이고, 본원이, 도시되고 설명된 특정 실시예에 한정되도 록 의도된 것은 아님을 이해해야 한다. 아래의 설명에 있어서, 도면의 여러 도에서 동일, 유사 혹은 대응하는 부분들을 설명하기 위해 동일한 참조 번호를 사용한다.

여기서 사용되는 "하나의(a, an)"라는 용어는 하나 혹은 하나 이상으로 정의된다. 여기서 사용되는 "복수(plurality)"라는 용어는 둘 혹은 둘 이상으로 정의된다. 여기서 사용된 "또다른(another)"이라는 용어는 적어도 두 번째 혹은 그 이상으로 정의된다. 여기서 사용된 "포함하는(including)" 및/또는 "갖는(having)"이라는 용어는 구비하는(comprising)으로 정의된다(즉, 개방 언어). 여기서 사용된 "연결된(coupled)"이라는 용어는, 반드시 직접적, 및 반드시 기계적이라야 하는 것은 아니지만 접속된다(connected)는 것으로 정의된다. 여기서 사용된 "프로그램"이라는 용어는 컴퓨터 시스템에서의 실행을 위해 설계된 명령어들의 시퀀스로 정의된다. "프로그램" 또는 "컴퓨터 프로그램"은, 서브루틴, 함수(function), 절차(procedure), 오브젝트 메소드, 오브젝트 구현, 실행가능 애플리케이션에서, 애플릿, 서브릿, 원시 부호(source code), 목적 부호(object code), 공유 라이브러리/동적 부하 라이브러리 및/또는 컴퓨터 시스템에서의 실행을 위해 설계된 그 외의 명령어 시퀀스를 포함할 수 있다.

이 문서 전체에 걸쳐 언급된 "일 실시예(one embodiment)", "소정의 실시예들(certain embodiments)", "하나의 실시예(an embodiment)" 또는 유사한 용어는, 실시예와 관련하여 설명된 특정한 특징, 구조, 또는 특성이 본 발명의 적어도 하나의 실시예에 포함되어 있다는 것을 의미한다. 따라서, 본 명세서 전체에 걸쳐 다 양한 위치에서 출현하는 어구들 모두가 반드시 동일한 실시예를 지칭하는 것은 아니다. 게다가, 특정한 특징, 구조, 또는 특성은 제한 없이 하나 이상의 실시예에서 임의의 적절한 방식으로 조합될 수도 있다.

하나의 지점에서 다음 지점으로의 패킷 전달을 위해 UDP 패킷과 같은 패킷이 사용되는 경우에, 이는, 보통, 모든 패킷의 완전한 수신 보증이 필수적인 것은 아닌 환경에서 사용된다. 일반적으로, 패킷 전부(each and every)가 수신자에게 도착할 필요보다 패킷 수신 타이밍이 중요한 경우에 UDP 및 유사 프로토콜들이 사용된다. 그 예는 오디오 및 비디오 데이터와 음성을 스트리밍하는 것이다. 그러한 데이터에서의 손실 패킷은 공지된 다양한 알고리즘에 의해 다루어질 수 있다. 모든 패킷이 수신되는 것이 확실히 바람직하다고 할 수 있지만, 그것이 단순히 최고 우위에 있는 것은 아니다.

손실 패킷의 재송신에 있어서의 "최대 성과(best effots)"의 보장을 돕기 위해 여러 프로토콜이 개발되어 왔지만, 이는 대개 복잡한 알고리즘, 추가적인 하드웨어 비용, 및/또는 상당한 계산상의 복잡성을 수반한다. 게다가, UDP 패킷 및 유사 프로토콜의 경우, 유용하기 위해 프로세스는 매우 빨라야만 하는데, 그 이유는 많은 예에서 패킷의 가용 수명이 매우 짧기 때문이다. 예를 들어, 오디오 데이터를 스트리밍하는데 UDP가 사용된다면, 재송신이 시작되고 손실 패킷을 재생 스트림에 삽입하기에 충분한 시간 내에 재송신이 수신되는 경우에만 손실 패킷이 대체될 수 있다. 그렇지 않으면, 어떠한 재송신 기술도 쓸모없다.

본 발명에 따른 소정의 실시예들은, 어떠한 핸드쉐이크도 요구하지 않고 송 신기 및 수신기에서 최소 혹은 추가가 없는 하드웨어를 사용하여 쉽게 구현되는 재송신 프로토콜을 이용하는 매우 간단하고 저렴한 알고리즘을 사용하여 손실 패킷의 상태를 개선하고자 한다. 추가로, 단순함으로 인해, 프로토콜은 신속한 재송신을 달성하기에 충분할 정도로 빠르고, 따라서 가용 수명이 끝나기 전에 손실 패킷이 대체될 수 있을 가능성을 증가시킨다.

이제, 도 1을 참조하면, 소정의 실시예들에 따른 예시적인 시스템의 블록도가 시스템(10)으로서 도시된다. 이러한 논의를 위해, 데이터 패킷 플로우에 대하여, 클라우드(20) 우측의 블록들은 수신 디바이스를 나타내고, 클라우드(20)의 좌측 블록들은 송신 디바이스 혹은 패킷 소스를 나타낸다. 정상 동작 동안, 송신 버퍼(12)는, 송신기(16)를 사용하여 송신하기 위해, 소스에 의해 조절된 속도로 소스(예컨대, 디스크 드라이브, 광 디스크, 방송된 신호를 위한 동조기 등)로부터 데이터를 수신한다. 수신된 데이터는, 각각 시퀀스 번호를 지닌, UDP 패킷 등의 패킷 시퀀스로서 정상적으로 포맷된다. 송신기(16)는, 네트워크, 또는 네트워크 대역폭이 허용하는 한 빠른, 20으로 도시된 그 외의 매체(예컨대, 무선 통신 링크)를 통해 수신기(18)로 패킷 시퀀스를 송신한다. 수신되면, 수신기(18)는, 예를 들어 오디오 혹은 비디오 플레이어 디바이스에 의한 후속 검색(subsequent retrieval)을 위해 수신된 패킷들을 수신 버퍼(24)에 배치시킨다.

모든 패킷들이 차례로 수신되는 한, 시스템은, 예를 들어 수신기 디바이스에서 패킷들의 소스로부터의 비디오 스트리밍의 재생을 허가하기 위해 정규 방식으로 기능한다. 동작이 진행되면, FIFO(first in first out) 디바이스로서 동작하는 송 신 버퍼(12)에는 신규 데이터가 로드되고, 이 신규 데이터는 역시 FIFO 버퍼로서 작동하는 수신 버퍼(24)로부터의 필요에 따라 유사하게 추출된다.

사용 중인 프로토콜로 인해, 어떤 원인으로 인해 송신된 패킷이 수신기 디바이스에 적절히 수신되지 않는 경우가 종종 있다. 이러한 예로서, 예를 들어, 수신된 패킷의 시퀀스 번호에서 갭을 주목하여 패킷의 부재를 검출한다. 이러한 검출은 이 도면에서 손실 패킷 검출기(28)로 표시된다. 손실 패킷의 검출시, 손실 패킷 검출기(28)는 재송신 요청의 전달을 요청한다. 이는, 송신기(34)를 통해 패킷 소스의 수신기(38)로의 재송신 요청을 전달하는, 재송신 요청 프로세서(32)로서 상징적으로 도시된다. 소정의 바람직한 실시예에서, 이러한 요청은 UDP, 또는 핸드쉐이크나 그 외의 확인이 없는 유사 프로토콜 패킷의 형태이고, 따라서 요청 전달이 보증되지 않더라도, 재송신 요청을 간단히 유지할 수 있다.

수신기(38)에서 재송신 요청이 수신되는 경우, 송신 버퍼(12)의 손실 패킷 탐색을 수행하는 재송신 요청 프로세서(40)에서 재송신 요청이 디코드되고 프로세스된다. 본원의 실시예의 신속성 및 단순함의 일부는 상기 탐색이 송신 버퍼(12)에서만 수행된다는 사실에 의거한다. 손실 패킷이 송신 버퍼(12)에 의해 폐기되지 않았다면, 송신 큐에 다시 배치되고 가장 빠른 가용 전송 시간에 송신기(16)를 사용하여 재송신된다. 손실 패킷이 송신 버퍼(12)에 다시 배치되면, 재송신 요청은 간단히 폐기된다. 패킷을 재송신하기 위한 어떠한 추가 노력도 필요하지 않다.

수신 버퍼(24)의 활성부에 위치될 시간에(즉, 검색된 패킷에 후속하는 패킷이 수신 디바이스에서 소모를 위해 수신 버퍼(24)로부터 끌어 내어지기 전에) 송신 패킷이 수신기(18)에서 수신되면, 재송신된 패킷은 수신된 패킷 스트림에서 사용될 수 있다. 재송신된 패킷이 너무 늦게 도착하면, 단순히 폐기된다.

이 프로토콜은, UDP 또는 유사 프로토콜 패킷 세션에서 손실된 패킷의 일부를 복구하기 위한 메커니즘을 제공하는 한편 데이터 처리율(throughput)을 떨어뜨리는 확인 혹은 부정적인 확인 혹은 그 외의 핸드쉐이킹 동작이 없게 된다. 게다가, 지연이 없으면 송신 버퍼 외측으로부터 기존(old) 패킷을 검색하는 단계에 직면하게 되고 지연이 없으면 재송신된 패킷이 수신 디바이스에 제때 수신될 것 같은지 여부를 예측하는 단계에 직면하게 된다. 설명된 프로세스는 여전히 간단하고, 송신 중에 손실된 패킷의 일부를 복구할 수 있다. 모든 패킷의 수신을 보증하지는 못하더라도, 사실상 어떠한 패널티도 초래하지 않는 한 손실 패킷에 대한 합리적인 복구 노력이 시도된다. 손실 패킷에 대한 탐색이 가능함에 따라 손실 패킷의 검출은 최소한의 계산 복잡도로 실행될 수 있다. 많은 시스템에서, 이는 현존하는 제어 프로세서 혹은 매우 간단한 상태 머신 혹은 그 외의 로직을 사용하여 달성될 수 있다. 주로 전송 대기시간(latency)에 의존하여, 상당한 수의 손실 패킷이 복구될 수 있다.

따라서, 소정의 실시예들에 따른 핸드쉐이크리스 통신을 위한 송신기 디바이스는, 패킷 소스로부터 패킷 수신 디바이스로 패킷의 시퀀스를 송신하는 송신기를 갖고, 패킷 시퀀스 내의 각 패킷은 그와 관련된 시퀀스 번호를 갖고, 상기 송신은 송신 버퍼로부터 다음 패킷의 검색과 상기 다음 패킷의 송신을 포함한다. 송신기는 특정한 패킷 시퀀스에 대해 재송신 요청을 수신한다. 재송신 요청은 개시 시퀀 스 번호(starting sequence number)와 시퀀스 패킷들의 수로 구성될 수 있다. 특정한 그룹의 패킷들이 송신 버퍼에서 이용 가능한 상태로 있다면, 특정 패킷들은 수신 디바이스로 재송신되고, 특정한 패킷이 송신 버퍼에서 이용 가능하지 않은 상태라면, 재송신 요청은 무시된다.

이제, 도 2를 참조하면, 수신 디바이스에 의해 실행되고 52에서 시작하는 예시적인 프로세스(50)가 도시된다. 54에서 패킷이 수신 및 버퍼링되고 그 이후 혹은 그 동안 58에서 시퀀스 번호가 체크된다. 이 예에서 시퀀스 번호는, 패킷 시퀀스 내의 패킷이 손실되었는지를 판별하기 위해 사용된다. 패킷이 수신되어 수신 버퍼(24)에 배치되거나, 버퍼(도시되지 않음)로부터 추출될 때마다, 62에서 버퍼 포인터는 갱신된다. 버퍼 포인터는, 수신 버퍼 내의 데이터의 다양한 속성들 - 이를테면, 미사용 데이터의 맨 위(top) 및 맨 아래(bottom) - 을 나타내기 위해 사용된다. 바람직한 실시예에서, 버퍼(24) 내의 패킷은, 시퀀스 내에서 다음 패킷과 이전 패킷을 나타내는 데이터와 각 시퀀스 패킷들이 관련되는 더블 링크 리스트를 사용하여 추적된다. 시퀀스가 갭을 포함한다면, 더블 링크 리스트는 "가장 근접한(most nearly)" 다음 혹은 이전 패킷을 가리킨다. 예를 들어, 버퍼 내의 패킷 시퀀스가 1, 2, 3, 5, 6..., 이라면, 갭은 패킷 번호 3과 패킷 번호 5 사이를 나타낸다. 따라서, 링크 리스트는 3 이후의 다음 패킷은 5로 표시할 것이고, 반대로, 5 이전의 패킷은 3으로 표시할 것이다.

리스트 내에서 갭이 추적되면, 바람직한 실시예에서는 제2 더블 링크 리스트를 사용한다. 제2 리스트는 어떠한 갭도 존재하지 않는 경우에는 널 값(null value)을 포함하지만, 갭이 존재하는 경우에는 시퀀스 번호에 의해 손실 패킷을 식별하는 데이터를 포함한다.

62에서는, 이들 리스트 각각과 새로운 데이터(fresh data)의 시작과 끝을 나타내는 포인터들이 갱신된다. 66에서, 프로세스는, 패킷이 손실되었는지, 즉, 패킷 시퀀스 번호 내에 갭이 존재하는지를 판별한다. 만약 아니라면, 제어는 54로 돌아가 다음 패킷의 수신을 기다린다. 만약 그렇다면, 70에서 재송신 요청이 발생되어 패킷의 스트림의 소스로 전달된다. 바람직한 실시예에 대한 수신기측의 동작은 아래 보다 상세히 설명될 것이다.

이제, 도 3을 참조하면, 플로우 차트(75)는 78에서 시작하여, 본 발명에 따른 실시예에서 재송신 요청 프로세서의 동작을 도시한다. 82에서 재송신 요청이 수신되면, 86에서 송신 버퍼(12)가 체크되어 재송신이 요청된 패킷이 존재하는지 여부를 판별한다. 90에서 패킷이 발견되면, 이는 94에서 다음 가용 전송 시간에 재송신된다. 그 다음 82로 되돌아 가서 다음 재송신 요청을 기다린다. 90에서 송신 버퍼(12)에서 패킷이 발견되지 않았다면, 98에서 재송신 요청은 무시되고 82로 다시 되돌아 가서 다음 재송신 요청을 기다린다.

따라서, 소정의 실시예들에 따른 핸드쉐이크리스 통신에서 사용하기 위한 재송신 방법은, 패킷 소스로부터 패킷 수신 디바이스로 패킷 시퀀스를 송신하는 단계 - 패킷 시퀀스 내의 각 패킷은 그들과 관련된 시퀀스 번호를 갖고, 상기 송신 단계는 송신 버퍼로부터의 다음 패킷을 검색하는 단계와 상기 다음 패킷을 전송하는 단계를 포함함 - ; 패킷 수신 디바이스에서, 수신된 패킷의 시퀀스 번호 중에서 갭이 존재하는지를 판별하여 패킷이 수신되지 않았는지를 판별하는 단계; 수신 디바이스로부터 송신 디바이스로 재송신 요청을 전달하는 단계 - 상기 재송신 요청은 시퀀스 번호의 갭을 채우도록 패킷의 특정 시퀀스에 대한 재송신을 요청하는 것임 - ; 패킷 소스에서, 특정 패킷의 시퀀스에 대한 재송신 요청을 수신하는 단계; 패킷 소스에서, 특정 패킷이 송신 버퍼 내에서 이용 가능한 상태로 있는지를 판별하는 단계; 특정 패킷이 송신 버퍼 내에서 이용 가능한 상태라면, 특정 패킷을 수신 디바이스로 재송신하는 단계; 및 특정 패킷이 송신 버퍼 내에서 이용 가능하지 않은 상태라면, 재송신 요청을 무시하는 단계를 수반한다.

도 4에서는, 원형 및 선형적으로 송신 및 수신 버퍼(12 및 14) 각각의 동작을 도시한다. 송신 버퍼(12)는 좌측에 도시되고, 수신 버퍼는 우측에 도시된다. 본 발명에 따른 소정의 실시예에서, 송신 및 수신 버퍼(12 및 24) 둘다 원형 FIFO 버퍼이다. 버퍼(12)의 경우에, 송신을 위한 큐 내에 있는 신규 데이터(및 가능하게는 일부 재송신 데이터)의 시작 및 끝을 표시하기 위해 두 개의 포인터(two pointers; 102 및 104)가 사용된다. 신규 데이터가 버퍼로 들어가면, 포인터(104)는 "NEW"로 표시된 화살표의 방향으로 전진한다. "NEW"로 표시된 버퍼의 영역은 전송될 데이터를 나타낸다. 기존 데이터는 "OLD"로 표시되고 유사한 범례(legend)의 화살표로 표시된다. 따라서, 신규 데이터가 전송을 위해 수신되면, 신규 데이터를 전달하는 영역은 포인터(104)로 표시된 끝으로 확장된다. 버퍼로부터 데이터가 추출되면, 포인터(102)는 "NEW"로 표시된 화살표의 방향으로 유사하게 이동한다.

이미 송신된 데이터는 신규 데이터에 의해 대체될 때까지 버퍼로부터 소거되지 않는다. 따라서, "OLD"로 표시된 원형 버퍼 부분은 가장 최근에 송신된 데이터를 포함할 것이다.

원형 버퍼(12) 아래 도시된 버퍼의 선형 표현에서, 도시된 예에서, 패킷 1-7은 이미 전송된 것으로 보여질 수 있다. 패킷 8은 화살표(108)에 의해 표시된 바와 같이 현재 전송 중인 것이고 패킷 9로 시작하는 추가 패킷은 전송을 기다리고 있는 중이다.

수신 버퍼(24)에서, 유사한 원형 버퍼가 사용될 수 있다. 그러나, 이러한 경우에, "OLD"로 표시된 데이터는 특히 현재 논의에 관련된 것은 아니다. 그러나, 버퍼(24)는 포인터(110)를 전진시키는 새롭게 수신된 데이터 및 포인터(116)를 전진시키는 새롭게 추출된 데이터와 유사한 방식으로 동작한다. 그러나, 신규 데이터는 FIFO 버퍼의 선형 표현상에 화살표(120)로 도시된 바와 같이, 손실 패킷을 나타내는 갭을 포함할 수도 있다.

도 5는, 소정의 바람직한 실시예에 따른 방식으로, 시퀀스 번호를 사용하여 패킷 시퀀스 내에서 갭을 검출하기 위한 수신 버퍼(24)에서의 동작을 보다 상세히 도시한다. 이 도면에서, 프로세스는 150으로 도시되고, 152에서 시작한다. 값 T는 현재 수신된 패킷의 패킷 시퀀스 번호를 나타내고, P는 이전에 수신된 패킷에 대한 패킷 시퀀스 번호를 나타낸다. 이 실시예에서, 수신 버퍼는 수신된 데이터에서 갭을 식별하기 위해 갭 링크 리스트로 칭한 관련 더블 링크 리스트를 갖는 메모리로 실현된다.

154에서, 프로세스는 패킷의 도착을 기다린다. 154에서 패킷이 도착하면, T는 P와 비교되고, T<P가 아니면 160으로 진행하여 T와 P가 다시 비교된다. 160에서 T>P+1이 아니면 패킷은 순서대로 수신되고 164로 진행되어 패킷이 다음 위치 내의 링 버퍼에 첨부된다. 전술된 바와 같은 링크 리스트를 사용하여 위치가 추적될 수 있다.

158에서, T<P인 경우, T<P는, 현재 패킷이 현재 패킷보다 더 낮은 번호로 매겨져 있음을 나타내고, 따라서 더 이전에 수신되었어야 했음을 나타내므로, 프로세스는 패킷이 속한 위치를 찾기 위해 갭 링크 리스트로 간다. 172에서, 패킷이 속한 위치가 발견되면, 적절한 위치에 패킷이 삽입된다. 만약 그렇지 않으면, 180에서 패킷은 폐기된다. 또 다른 경우에, 154로 되돌아 가서 다음 패킷의 도착을 기다린다.

160에서, T>P+1인 경우, 패킷 내의 갭과 직면하게 된다. 184에서, 이 갭 정보가 갭 링크 리스트 내에 기록되고, 패킷은 링 버퍼 내의 패킷에 첨부된다. 그 다음 188에서 재송신 요청이 실시되고 프로세스는 154로 되돌아 가서 다음 패킷을 기다린다.

당업자는, 단지 일례인 갭 링크 리스트를 사용하는 상기 예와 함께, 수신 패킷의 스트림에서 갭의 위치를 추적하기 위해 많은 메커니즘이 사용될 수 있음을 이해할 것이다. 그 외의 실시예에서, 버퍼는 반드시 원형 버퍼일 필요는 없고, 수신된 패킷 내의 갭은 반드시 링크 리스트 혹은 더블 링크 리스트를 사용하여 추적될 필요는 없다. 당업자에게는 그 외의 실시예들도 떠오를 것이다.

본 발명에 따른 다양한 실시예들을 사용하여, 손실 패킷의 시퀀스에 대한 재송신 요청이 발생되고 수신측에 신속하게 전송될 수 있다. 또한, 효과적인 재송신의 가능성을 최대화하기 위해 패킷이 송신측에 위치할 수도 있고(아닐 수도 있음) 송신측에서 매우 신속하게 재송신될 수도 있다(아닐 수도 있음). 게다가, 프로세스는 구현하기 간단하고, 그 결과 최소한의 비용 및 복잡도로 수신기에서 패킷의 스트림 내의 갭의 수를 감소시킬 수 있다.

여기서 소정의 실시예들은 설명된 기능을 수행하는 특정 회로와 관련하여 설명되었지만, 하나 이상의 프로그래밍된 프로세서 상에서 실행된 등가의 소프트웨어 혹은 팜웨어 구현을 사용하여 상기 회로 기능이 수행되는 그 외의 실시예들이 생각될 수도 있다. 범용 컴퓨터, 마이크로프로세서 기반 컴퓨터, 마이크로제어기, 광 컴퓨터, 아날로그 컴퓨터, 전용 프로세서, 애플리케이션 특정 회로 및/또는 전용의 배선에 의한 논리 및 아날로그 회로가 사용되어 대안적인 등가의 실시예들을 구성할 수도 있다. 특수 목적 하드웨어 및/또는 전용 프로세서 등의 하드웨어 컴포넌트 등가물을 사용하여 그 외의 실시예들이 구현될 수 있다.

소프트웨어 및/또는 팜웨어 실시예는 임의의 적절한 전자 혹은 컴퓨터 판독가능 기억 매체(예를 들어, 디스크 기억장치, ROM(Read Only Memory) 디바이스, RAM(Random Access Memory) 디바이스, 네트워크 메모리 디바이스, 광 기억 소자, 자기 기억 소자, 광-자기 기억 소자, 플래시 메모리, 코어 메모리 및/또는 그 외의 등가의 휘발성 및 비휘발성 기억 기술들) 상에 저장될 수 있는 프로그래밍 명령어 - 소정의 예에서 플로우 차트 형태로 광범위하게 상술됨 - 를 실행하는 프로그램된 프로세서를 사용하여 구현될 수도 있고 및/또는 임의의 적절한 전자 통신 매체를 통해 전송될 수 있다. 그러나, 당업자라면, 상술된 프로세스들이, 현재의 교시를 참작하여, 본 발명의 실시예들로부터 벗어나지 않고, 임의의 수의 변경 및 많은 적절한 프로그래밍 언어로 구현될 수 있음을 이해할 것이다. 예를 들어, 본 발명의 소정의 실시예들로부터 벗어나지 않고, 실행된 소정의 동작들의 순서가 종종 달라질 수 있고, 추가 동작이 추가되거나 동작들이 삭제될 수 있다. 본 발명의 소정의 실시예들로부터 벗어나지 않고 에러 트래핑이 추가 및 개선될 수 있고 및/또는 사용자 인터페이스 및 정보 프리젠테이션에 있어서 변경이 실시될 수 있다. 그러한 변경이 계획되고 등가물이 고려된다.

본원의 소정의 실시예들에 대한 상기 설명은 하나의 송신기와 하나의 수신기 사이의 동작에 중점을 두었다. 그러나, 본 발명에 따른 그 외의 실시예들은, 네트워크 대역폭의 증가 없이 서비스 수신측의 수를 증가하는 멀티캐스트 기법에 의해 다수의 수신기를 하나의 송신기가 서브하는 경우에도 적용가능하다. 어떠한 핸드쉐이크 메커니즘도 존재하지 않으므로, 재송신 요청 프로세서는 동일 방식으로 하나 이상의 수신기로부터의 요청을 취급할 수 있다.

소정의 예시적인 실시예가 설명되었지만, 전술한 설명의 견지에서 많은 대안, 수정, 치환 및 변경이 당업자에게는 명백할 것이다.

Claims (18)

1. 핸드쉐이크리스 통신(handshakeless communication)에서 사용하기 위한 재송신 방법으로서,

   패킷 소스로부터 패킷 수신 디바이스로 패킷 시퀀스를 송신하는 단계 - 상기 패킷 시퀀스 내의 각 패킷은 그들과 관련된 시퀀스 번호를 갖고, 상기 송신 단계는 송신 버퍼로부터 다음 패킷을 검색하는 단계와 상기 다음 패킷을 송신하는 단계를 포함함 - ;

   상기 패킷 수신 디바이스에서, 수신된 패킷들의 시퀀스 번호에서 갭이 존재하는지를 판별하여 패킷 혹은 패킷 시퀀스가 수신되지 않았는지를 판별하는 단계;

   상기 수신 디바이스로부터 상기 송신 디바이스로 재송신 요청을 전달하는 단계 - 상기 재송신 요청은, 시퀀스 번호의 갭을 채우는 패킷의 특정 시퀀스의 재송신을 요청하는 것임 - ;

   상기 패킷 소스에서, 상기 특정 패킷 시퀀스에 대한 상기 재송신 요청을 수신하는 단계;

   상기 패킷 소스에서, 상기 특정 패킷 시퀀스가 상기 송신 버퍼에서 이용 가능한 상태인지를 판별하는 단계;

   상기 특정 패킷 시퀀스가 상기 송신 버퍼에서 이용가능한 상태라면, 상기 특정 패킷을 상기 수신 디바이스로 재송신하는 단계; 및

   상기 특정 패킷 시퀀스가 상기 송신 버퍼에서 이용가능한 상태가 아니라면, 상기 재송신 요청을 무시하는 단계

   를 포함하는 재송신 방법.
2. 제1항에 있어서, 상기 수신 디바이스는 수신 버퍼를 갖고, 수신된 패킷은 상기 수신 버퍼에 배치되고, 상기 수신 버퍼 내의 각 패킷의 위치는 제1 링크 리스트를 사용하여 추적되는 재송신 방법.
3. 제2항에 있어서, 상기 제1 링크 리스트는, 시퀀스 번호에 갭이 존재하는 경우 상기 패킷 시퀀스에서 인접 패킷들을 지시(point)하기 위해, 또는 상기 패킷 시퀀스에서 가장 가깝게 인접한 패킷들을 지시하기 위해 포인터를 사용하는 재송신 방법.
4. 제2항에 있어서, 수신된 시퀀스 번호들에서 갭의 존재는 제2 링크 리스트를 사용하여 추적되고, 상기 제2 링크 리스트는 상기 버퍼 내에 다음 및 이전 패킷 시퀀스 번호를 갖는 패킷이 있는 각 패킷에 대해서는 널 입력(null entry)을 포함하고, 상기 제2 링크 리스트는 수신된 패킷들에서 갭으로 인해 손실된 각 시퀀스 번호에 대한 시퀀스 번호를 갖는 재송신 방법.
5. 제3항에 있어서, 수신된 시퀀스 번호들에서 갭의 존재는 제2 링크 리스트를 사용하여 추적되고, 상기 제2 링크 리스트는 상기 버퍼 내에 다음 및 이전 패킷 시 퀀스 번호를 갖는 패킷이 있는 각 패킷에 대해서는 널 입력(null entry)을 포함하고, 상기 제2 링크 리스트는 수신된 패킷들에서 갭으로 인해 손실된 각 시퀀스 번호에 대한 시퀀스 번호를 갖는 재송신 방법.
6. 제2항에 있어서, 수신된 시퀀스 번호들에서 갭의 존재는 제2 링크 리스트를 사용하여 추적되는 재송신 방법.
7. 제2항에 있어서, 상기 제1 링크 리스트는 더블 링크 리스트를 포함하는 재송신 방법.
8. 제2항에 있어서, 상기 수신 버퍼는 원형 버퍼를 포함하는 재송신 방법.
9. 제3항에 있어서, 상기 송신 버퍼는 원형 버퍼를 포함하는 재송신 방법.
10. 제1항에 있어서, 상기 패킷은 UDP 포맷 패킷을 포함하는 재송신 방법.
11. 제1항에 있어서, 상기 패킷 시퀀스 내의 갭의 존재는 갭 링크 리스트를 사용하여 상기 수신 디바이스에서 추적되는 재송신 방법.
12. 핸드쉐이크리스 통신(handshakeless communication)에서 사용하기 위한 재송 신 방법으로서,

    패킷 소스로부터 패킷 수신 디바이스로 패킷 시퀀스를 송신하는 단계 - 상기 패킷 시퀀스 내의 각 패킷은 그들과 관련된 시퀀스 번호를 갖고, 상기 송신 단계는 원형 송신 버퍼로부터 다음 패킷을 검색하는 단계와 상기 다음 패킷을 송신하는 단계를 포함함 - ;

    상기 패킷 수신 디바이스에서, 수신된 패킷들의 시퀀스 번호에서 갭이 존재하는지를 판별하여 패킷이 수신되지 않았는지를 판별하는 단계;

    상기 수신 디바이스로부터 상기 송신 디바이스로 재송신 요청을 전달하는 단계 - 상기 재송신 요청은, 시퀀스 번호의 갭을 채우는 패킷의 특정 시퀀스의 재송신을 요청하는 것임 - ;

    상기 패킷 소스에서, 상기 특정 패킷에 대한 상기 재송신 요청을 수신하는 단계;

    상기 패킷 소스에서, 상기 특정 패킷이 상기 송신 버퍼에서 이용 가능한 상태인지를 판별하는 단계;

    상기 특정 패킷이 상기 송신 버퍼에서 이용가능한 상태라면, 상기 특정 패킷을 상기 수신 디바이스로 재송신하는 단계; 및

    상기 특정 패킷이 상기 송신 버퍼에서 이용가능한 상태가 아니라면, 상기 재송신 요청을 무시하는 단계

    를 포함하고,

    상기 수신 디바이스는 원형 수신 버퍼를 갖고, 수신된 패킷은 상기 수신 버 퍼에 배치되고, 상기 수신 버퍼 내의 각 패킷의 위치는 제1 링크 리스트를 사용하여 추적되고, 상기 제1 링크 리스트는 시퀀스 번호에 갭이 존재하는 경우 상기 패킷 시퀀스에서 인접 패킷들을 지시하기 위해, 또는 상기 패킷 시퀀스에서 가장 가깝게 인접한 패킷들을 지시하기 위해 포인터를 사용하고,

    수신된 시퀀스 번호들에서 갭의 존재는 제2 링크 리스트를 사용하여 추적되고, 상기 제2 링크 리스트는 상기 버퍼 내에 다음 및 이전 패킷 시퀀스 번호를 갖는 패킷이 있는 각 패킷에 대해서는 널 입력(null entry)을 포함하고, 상기 제2 링크 리스트는 수신된 패킷들에서 갭으로 인해 손실된 각 시퀀스 번호에 대한 시퀀스 번호를 갖는 재송신 방법.
13. 제12항에 있어서, 상기 패킷은 UDP 포맷 패킷인 재송신 방법.
14. 핸드쉐이크리스 통신(handshakeless communication)을 위한 송신기 디바이스로서,

    패킷 소스로부터 패킷 수신 디바이스로 패킷 시퀀스를 송신하는 송신기 - 상기 패킷 시퀀스 내의 각 패킷은 그들과 관련된 시퀀스 번호를 갖고, 상기 송신은 송신 버퍼로부터 다음 패킷의 검색과 상기 다음 패킷의 송신을 포함함 - ;

    특정 패킷 시퀀스에 대한 재송신 요청을 수신하는 수신기; 및

    상기 특정 패킷 시퀀스가 상기 송신 버퍼에서 이용 가능한 상태인지를 판별하는 수단

    을 포함하고,

    상기 특정 패킷이 상기 송신 버퍼에서 이용가능한 상태라면, 상기 특정 패킷을 상기 수신 디바이스로 재송신하고,

    상기 특정 패킷이 상기 송신 버퍼에서 이용가능한 상태가 아니라면, 상기 재송신 요청을 무시하는 송신기 디바이스.
15. 제14항에 있어서, 상기 송신 버퍼는 원형 버퍼를 포함하는 송신기 디바이스.
16. 제14항에 있어서, 상기 패킷은 UDP 포맷 패킷을 포함하는 송신기 디바이스.
17. 제14항에 있어서, 상기 패킷은 패킷 수신에 대한 확인이 없는(no acknowledgement) 핸드쉐이크리스 프로토콜을 사용하여 송신되는 송신기 디바이스.
18. 제14항에 있어서, 상기 재송신 요청은 확인되지 않는 송신기 디바이스.

Images