KR102178310B1 - Dds 통신의 연속성 보장을 위한 방법 - Google Patents

Abstract

본 발명은 DDS 통신의 연속성 보장을 위한 방법에 관한 것으로, 더욱 상세하게는 데이터 분산 서비스 통신 미들웨어를 통해 신뢰성 통신을 수행할 때 통신의 연속성이 보장될 수 있도록 하는 DDS 통신의 연속성 보장을 위한 방법에 관한 것이며, 특정 Reader의 오류로 인한 다른 노드들의 통신 지연 및 실패를 해소하기 위하여 일정 횟수동안 AckNack 응답이 없는 Reader는 없다고 간주하고 통신을 계속해 나가는 것으로, Writer와 매치된 Reader중 특정 Reader가 오류가 생겼다 하더라도, 다른 매치된 Reader들에게 영향 없이 연속적인 통신이 가능하도록 하는 제1단계와, 오류가 생겼던 Reader가 다시 복구되어 통신이 가능해졌을 때 별도의 작업 없이 이어서 데이터 송수신이 가능하도록 하는 제2단계가 포함되어 매치된 Reader의 상황에 따라 끊김 없이 통신이 가능하도록 하는 것을 특징으로 한다.

Description

DDS 통신의 연속성 보장을 위한 방법{Method for Guaranteeing Continuously DDS communication}

본 발명은 DDS 통신의 연속성 보장을 위한 방법에 관한 것으로, 더욱 상세하게는 데이터 분산 서비스 통신 미들웨어를 통해 신뢰성 통신을 수행할 때 통신의 연속성이 보장될 수 있도록 하는 DDS 통신의 연속성 보장을 위한 방법에 관한 것이다.

일반적으로 데이터 분배 서비스(Data Distribution Service, DDS)는 분산 환경에서 다수의 이기종 정보처리 노드들 간의 실시간, 고성능 데이터 교환을 목적으로 OMG(Object Management Group)에서 정의한 미들웨어 표준 규격이다.

DDS는 데이터 중심의 발간-구독(Publish-Subscribe) 방식으로 노드들 간의 데이터 분배 방식을 표준화함으로써 복잡한 분산 데이터 처리체계 개발 용이성, 재사용성, 신뢰성, 유지보수성, 확장성, 상호 운용성을 크게 향상시킬 수 있다.

이러한 이유로 DDS는 이미 국방 분야의 다대다 데이터 분배 미들웨어 표준으로 자리 잡았다.

RTI의 Connext는 전체 DDS 미들웨어 시장의 70 ~ 80%를 차치하는 상용 DDS 미들웨어의 대표적인 제품으로 미 해군 함정, 차세대 전투 체계, UGV, SCADA, 도쿄 지능형 교통통제 시스템 등에 실제로 적용되어 사용되고 있다.

PrismTech의 Vertex OpenSplice의 경우는 오픈소스 형태로 DDS 미들웨어를 제공하고 있으며, 탈레스 사의 TACTICOS 무기체계에 실제로 적용되었다.

국내에서도 충남대의 ReTiCom, ETRI의 EDDS, MDS 테크놀로지의 NeoDDS 등 국산 DDS 미들웨어 상용화를 위한 노력이 지속적으로 이루어지고 있다.

이와 같은 DDS 미들웨어 기반의 응용 시스템은 중앙 집중식 데이터 관리 구조가 아닌 Pub-Sub 모델 기반으로 동작하므로, 분산 환경에서 각각의 시스템 컴포넌트들이 동적으로 데이터 도메인을 구성하면서 효율적으로 데이터 전송을 하는 것이 가능하다.

즉, 시스템을 정상적으로 운영하면서 시스템을 구성하는 컴포넌트들의 자유로운 참여나 탈퇴가 가능하다.

DDS 응용 시스템은 확장성 있는 시스템 구조를 제공하지만, 수백 개 이상의 노드와 응용으로 구성된 대규모 시스템인 경우 시스템에서 오류가 발생한 경우 오류의 발생 시점과 원인을 파악하기 어려운 문제점이 있었다.

대한민국 공개특허공보 공개번호 제10-2018-0015027호

본 발명은 상술한 문제점을 해결하기 위해 안출된 것으로서, 데이터 분산 서비스 통신 미들웨어를 통해 신뢰성(Reliable) 통신을 수행할 때 통신의 연속성이 보장될 수 있도록 하는 DDS 통신의 연속성 보장을 위한 방법을 제공하는 것이다.

상술한 목적을 달성하기 위한 본 발명의 DDS 통신의 연속성 보장을 위한 방법은 Reliable 통신모드 시 특정 Reader의 오류로 인한 다른 노드들의 통신 지연 및 실패를 해소하기 위하여 일정 횟수동안 AckNack 응답이 없는 Reader는 없다고 간주하고 통신을 계속해 나가는 것으로, Writer와 매치된 Reader중 특정 Reader가 오류가 생겼다 하더라도, 다른 매치된 Reader들에게 영향 없이 연속적인 통신이 가능하도록 하는 제1단계와; 오류가 생겼던 Reader가 다시 복구되어 통신이 가능해졌을 때 별도의 작업 없이 이어서 데이터 송수신이 가능하도록 하는 제2단계가 포함되어; 매치된 Reader의 상황에 따라 끊김 없이 통신이 가능하도록 하는 것을 특징으로 한다.

제1단계는 Writer가 데이터를 전송할 때 HeartBeat 메시지를 함께 보내면서 횟수 1을 증가시키는 단계와, Reader로부터 ACKNACK 메시지를 수신하면 횟수를 초기화시키는 단계와, 증가된 횟수가 미리 설정된 횟수보다 같거나 클 경우, 해당 Reader의 상태를 INACTIVE 상태로 변경하고 없는 것처럼 동작하는 단계를 포함할 수 있다.

제2단계는 INACTIVE 상태인 Reader의 상태가 복구되어 Writer로부터 새로운 데이터와 Heartbeat 메시지를 다시 전송받는 단계와, 이에 대한 응답으로 Reader로부터 ACKNACK 메시지를 수신하는 단계와, Writer가 INACTIVE상태인 Reader로부터 AckNack 메시지를 수신받게 되면 해당 Reader의 상태를 다시 ACTIVE로 변경하고 통신을 이어가는 단계를 포함할 수 있다.

이상에서 설명한 바와 같은 본 발명의 DDS 통신의 연속성 보장을 위한 방법에 따르면, 데이터 분산 서비스 통신 미들웨어를 통해 신뢰성(Reliable) 통신을 수행할 때 통신의 연속성이 보장될 수 있도록 하는 효과가 있다.

도 1은 DDS 엔티티 구조의 예시를 나타낸 도면이며,
도 2는 Writer와 ReaderProxy와의 관계를 나타낸 도면이며,
도 3은 데이터 Loss 없는 경우의 신뢰성 통신 프로세스를 나타낸 도면이며,
도 4는 데이터 Loss 있는 경우의 신뢰성 통신 프로세스를 나타낸 도면이며,
도 5는 기존 신뢰성 통신 프로세스 흐름도를 나타낸 플로우차트이며,
도 6은 본 발명의 일실시예에 따른 신뢰성 통신 프로세스를 나타낸 도면이며,
도 7은 본 발명의 일실시예에 따른 신뢰성 통신 프로세스에서 ACTIVE->INACTIVE 과정 프로세스의 예시를 나타낸 도면이며,
도 8은 본 발명의 일실시예에 따른 신뢰성 통신 프로세스에서 ACTIVE->INACTIVE 과정 프로세스의 예시를 나타낸 플로우차트이며,
도 8은 본 발명의 일실시예에 따른 신뢰성 통신 프로세스에서 INACTIVE->ACTIVE 과정 프로세스의 예시를 나타낸 플로우차트이다.

이하, 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자가 본 발명을 용이하게 실시할 수 있도록 상세히 설명하기 위하여, 본 발명의 바람직한 실시예를 첨부한 도면을 참조하여 상세하게 설명한다.

먼저, DDS(Data Distribution Service)는 OMG(Object Management Group)에서 국제 표준으로 제정한 데이터 중심의 발간-구독(Publish-Subscribe) 방식의 통신 미들웨어로, 아래와 같은 특징으로 동작한다.

DDS는 22가지의 QoS(통신품질보장정책)을 제공하며, 이 QoS를 통해 사용자는 여러 통신 기능 활용이 가능하며, 다양한 통신 환경 설정이 가능하다.

DDS 표준 QoS 중 'Reliability'는 통신의 신뢰성에 관한 항목으로 BEST_EFFROT(최선형)과, RELIABLE(신뢰형)의 2가지 옵션을 제공한다.

BEST_EFFORT(최선형)은 데이터 통신의 신뢰성을 보장하지 않는 옵션으로, 통신 중간에 일부 패킷이 유실되는 것과 상관없이 연속적으로 데이터 송수신을 수행하며, 신뢰성 보다는 실시간성이 중요한 시스템에서 사용하는 것이 알맞다.

RELIABLE(신뢰형)은 데이터 통신의 신뢰성을 보장해주는 옵션으로, HeartBeat/AckNack 메시지를 통해 유실되는 패킷에 대해서는 재전송을 수행하며, 실시간성보다 신뢰성이 중요한 시스템에 사용하는 것이 알맞다.

HeartBeat는 RELIABLE(신뢰형) 통신시에 Writer가 Reader에게 전송한 데이터를 Reader 측에서 정상적으로 모두 수신했는지 여부를 체크하기 위한 메시지로, Writer가 Reader에게 주기적으로 전송한다.

AckNack는 HeartBeat 메시지에 대한 응답메시지로, Writer가 Reader에게 전송한 데이터에 대해 받은 데이터와 못 받은 데이터를 비트맵형식으로 표기한 메시지로, Reader가 Writer에게 전송한다.

RELIABLE(신뢰형) 통신시에 Writer는 재전송을 위해 History 데이터들을 사용자가 지정한 일정 개수만큼 History Cache(메모리 큐)에 보관한다.

이때, 해당 개수가 초과되면, 메모리에 보관된 데이터 중 가장 오래된 데이터부터 Reader들로부터 AckNack 메시지를 모두 수신했는지 체크하여 삭제하고, 새로운 데이터를 저장한다.

Reader 중 하나라도 AckNack 메시지를 못 받았을 경우, Writer는 새로운 데이터를 전송하지 못하고 AckNack을 모두 받을 때까지 대기한다.

이와 같은 DDS의 동작 방식으로 인해 RELIABLE(신뢰형) 통신시에 Writer와 매치(Matched)된 Reader가 특정 사유(시스템 오류, 네트워크 불안정 등)로 인해 데이터를 수신할 수 없거나, 수신한 데이터에 대한 AckNack 응답메시지를 송신할 수 없을 경우, Writer는 새로운 데이터를 송신하지 못하고 무한정 대기하게 되는 문제가 발생한다.

이때, 이 하나의 Writer가 여러 Reader와 매치되었고, 그 중 하나의 Reader가 응답을 하지 못하는 상황이라면, 해당 Reader 뿐만 아니라 매치된 모든 정상 상태의 Reader들까지도 데이터를 수신할 수 없게 된다.

왜냐하면, Writer가 AckNack 메시지 수신을 무한 대기 중이기 때문이다.

DDS 구조의 주요 엔티티로는 도 1 및 도2에 나타낸 바와 같이, StatelessWriter는 디스커버리용 Writer이고, StatefulWriter는 데이터 통신용 Writer이고, ReaderProxy는 매치된 Reader 개수 만큼 생성되며, 각각의 Proxy에는 Reader의 정보가 저장되고, HistoryCache는 Writer가 발간하는 데이터 저장소이고, CacheChange는 Writer가 발간하는 데이터로써 HistoryCache에 저장되고, ChangeForReader는 발간된 CacheChange에 대해 매치된 Reader들의 수신 상태를 관리한다.

데이터 Loss 없는 경우의 DDS가 Reliable(신뢰성) 통신을 하는 프로세스는 도 3에 나타낸 바와 같이, 좌측이 Writer측의 HistoryCache이고, 우측은 Reader측의 HistoryCache를 나타낸 것이다.

양측의 HistoryCache size는 8로 동일하다.

먼저 Writer가 데이터를 1부터 8까지 전송하면서, 4번째 데이터마다 HeartBeat 메시지를 함께 보낸다.

이때, HeartBeat 메시지를 보내는 간격은 사용자가 설정 가능 하다.

이어서, Writer의 HistoryCache에 있는 데이터, 즉, 재전송이 가능한 데이터인 1부터 4까지의 시퀀스 번호를 갖는 데이터를 정상적으로 수신했는지를 묻는 HeartBeat 1-4 메시지를 수신하면, Reader는 자신이 수신한 데이터 목록인 HistoryCache에서 해당 시퀀스 번호의 데이터를 모두 수신했는지 확인한다.

이어서, 모두 수신했으면 ACK 1-4로 응답한다.

이러한 HeartBeat와 AckNack 메시지를 주고 받는 프로세스를 반복하며 신뢰성 보장형 통신을 하며, 매치된 Reader가 여러 개일 경우 동일한 작업을 별도 스레드로 동작한다.

한편, 데이터 Loss 있는 경우의 DDS가 Reliable(신뢰성) 통신을 하는 프로세스는 도 4에 나타낸 바와 같이, Writer가 시퀀스번호 1부터 4까지의 데이터 4개를 송신 후 HeartBeat 1-4를 송신한다.

이어서, Reader는 자신이 수신한 데이터 목록인 HistoryCache에서 해당 1-4 데이터를 모두 받았는지 체크한다.

이어서, 예를 들어, 3번 데이터를 받지 못했다면 ACK 1-2, NACK 3 메시지로 응답한다.

이어서, Writer는 NACK 메시지에 해당하는 3번 데이터를 재전송한다.

이어서, 이후 9번 데이터를 보낼 때에는 Writer의 HistroyCache가 꽉찼기 때문에, 가장 오래된 1번 데이터가 모든 Reader로부터 ACK를 받았는지 체크를 한 후, 맞다면 삭제하고 9번 데이터를 덮어쓴다.

하지만 매치된 Reader 중 하나의 Reader라도 ACK 메시지를 보내오지 않았다면 Writer는 9번 데이터를 송신하지 못하고, 1번 데이터에 대한 ACK를 기다리게 된다.

만일 Reader가 시스템이나 네트워크상의 오류로 ACK를 보낼 수 없는 상황이라면, Writer는 무한정 대기하게 된다.

전반적인 프로세스 흐름은 도 5에 나타낸 바와 같이, 먼저, 응용프로그램으로부터 새로운 데이터 전송 요청이 있으면(S110), Writer의 HistoryCache에 빈자리가 있는지 확인하고(S120), HistoryCache에 빈자리가 있으면 HistoryCache에 새로운 데이터를 저장하고(S160), 이어서 새로운 데이터를 Reader로 전송하면서(S170), Heartbeat도 같이 전송한다(S180).

그러나, Writer의 HistoryCache에에 빈자리가 없으면, HistoryCache의 첫 번째 데이터에 대해 모든 Reader로부터 Ack 메시지를 받았는지를 확인하고(S130), 모든 Reader로부터 Ack 메시지를 받았으면, Writer의 HistoryCache의 첫 번째 데이터를 삭제하고(S150), 이어서, Writer의 HistoryCache에 새로운 데이터를 저장하고(S160), 이어서 새로운 데이터를 Reader로 전송하면서(S170), Heartbeat도 같이 전송한다(S180).

한편, 모든 Reader로부터 Ack 메시지를 받지 않았으면, HistoryCache의 첫 번째 데이터에 대해 모든 Reader로부터 Ack 메시지를 받을 때까지 일정 시간을 대기하게 된다(S140).

이에, 본 발명에 따른 신뢰성 통신 프로세스는 도 6 및 도 7에 나타낸 바와 같이, 특정 Reader의 오류로 인한 다른 노드들의 통신 지연 및 실패를 해소하기 위하여 일정 횟수 동안 AckNack 응답이 없는 Reader는 없는 것으로 간주하고 나머지 Reader만으로 통신을 계속해 나가도록 한다.

먼저, 미리 최대 Heartbeat하는 횟수(MAX_HB_CNT)를 정의하고, Writer는 매치된 각각의 Reader에 대해 status와 heartbeating_count 속성을 관리한다.

heartbeating_count란, Reader가 Writer가 보낸 Heartbeat 메시지에 응답하지 않은 횟수로, Heartbeat 메시지를 보낼 때마다 +1 되고, ACKNACK 메시지를 수신하면 초기화된다.

이 heartbeating_count가 MAX_HB_CNT과 같거나 커질 경우 해당 Reader의 status를 INACTIVE 상태로 변경하고 마치 없는 것처럼 동작한다.

즉, 모든 Reader에게 Data와 Heartbeat 메시지를 똑같이 송신하지만, Writer의 HistoryCache가 꽉찼을 경우, 첫 번째 데이터가 ACTIVE 상태인 Reader들에게만 Ack 된 것이 확인되면, 해당 데이터를 삭제하고 새로운 데이터를 발간하는 것이다.

이때, 일정 기간 동안 응답이 없는 Reader를 삭제하지 않고 INACTIVE로 설정하는 이유는 시스템 오류나 네트워크 불안정 등의 이유로 통신을 할 수 없던 상태였던 Reader가 다시 통신이 가능한 상태로 복구되었을 경우, 마치 아무 일 없었던 것처럼 유연하게 통신을 이어가도록 하기 위함이다.

한편, INACTIVE 상태인 Reader가 상태가 복구되어 Writer로부터 새로운 메시지와 Heartbeat 메시지를 다시 받게 되면, 이에 대한 응답메시지를 보낼 것이다.

이때 Writer가 INACTIVE 상태인 Reader로부터 AckNack 메시지를 받게 되면 해당 Reader의 상태를 다시 ACTIVE로 변경하고 통신을 이어가게 된다.

이렇게 함으로써, 오류로 통신이 불가능한 Reader가 INACTIVE 상태인 동안은 신뢰성을 보장하지는 못하지만, 즉, 모든 데이터를 100% 수신한다는 보장은 못하지만, 전체 통신 노드들의 통신에 영향이 없는 것이다.

한편, 사용자가 무조건 신뢰성 100% 보장 통신을 원한다면, MAX_HB_CNT를 INTEGER 최대 값으로 설정하면 될 것이다.

본 발명에 따른 프로세스 흐름도는 도 8에 나타낸 바와 같이, 먼저, 최대 Heartbeat하는 횟수인 MAX_HB_CNT를 설정하고(S211), Writer와 매치된 모든 Reader를 초기화(status = ACTIVE, heartbeating_count = 0) 한다(S212).

이어서, 응용프로그램으로부터 새로운 데이터 전송 요청이 있으면(S213), Writer의 HistoryCache에 빈자리가 있는지 확인하고(S214), HistoryCache에 빈자리가 있으면 HistoryCache에 새로운 데이터를 저장하고(S219), 이어서 새로운 데이터를 Reader로 전송하면서(S220), Heartbeat도 같이 전송한다(S221).

이어서, 모든 Reader의 heartbeating_count가 1씩 증가(heartbeating_count += 1)되고(S222), Reader마다 heartbeating_count가 최대 Heartbeat하는 횟수보다 크게 되면(S223), 해당 Reader의 상태는 INACTIVE로 변경(status = INACTIVE)한다(S224).

그러나, Writer의 HistoryCache에 빈자리가 없으면, HistoryCache의 첫 번째 데이터에 대해 모든 Reader로부터 Ack 메시지를 받았는지를 확인하고(S215), 모든 Reader로부터 Ack 메시지를 받았으면, Writer의 HistoryCache의 첫 번째 데이터를 삭제하고(S218), 이어서, Writer의 HistoryCache에 새로운 데이터를 저장하고(S219), 이어서 상술한 S220 단계 내지 S224 단계를 수행한다.

한편, 모든 Reader로부터 Ack 메시지를 받지 않았으면, Ack 메시지를 전송하지 않은 Reader의 상태를 INACTIVE로 변경(UnAcked Reader의 Proxy status == INACTIVE)하고(S216), HistoryCache의 첫 번째 데이터에 대해 모든 Reader로부터 Ack 메시지를 받을 때까지 일정 시간을 대기하게 된다(S217).

아울러, 도 9에 나타낸 바와 같이, Reader로부터 ACK 메시지를 수신하게 되면(S310), 해당 Reader의 상태를 ACTIVE로 변경(Status==ACTIVE)하고(S320), 이어서, 해당 Reader를 초기화하면서 heartbeating_count를 초기화(heartbeating_count = 0)하고(S340), 해당 Reader의 상태를 ACTIVE로 변경(Status==ACTIVE)이 안됐으면, 해당 Reader의 상태가 ACTIVE가 되도록(status=ACTIVE) 대기한다(S330).

이상에서 설명한 바와 같은 본 발명의 DDS 통신의 연속성 보장을 위한 방법에 따르면, 데이터 분산 서비스 통신 미들웨어를 통해 신뢰성 통신을 수행할 때 통신의 연속성이 보장될 수 있도록 하는 것으로, 매치된 Reader의 상황에 따라 끊김 없이 유연한 통신이 가능하고, Writer와 매치된 Reader 중 특정 Reader가 오류가 생겼다 하더라도, 다른 매치된 Reader들에게 영향 없이 연속적인 통신이 가능하고, 오류가 생겼던 Reader가 다시 복구되어 통신이 가능해졌을 때 별도의 작업 없이 이어서 데이터 송수신이 가능한 효과가 있다.

한편, 본 발명에 따른 단계 S211 내지 단계 S224 및 단계 S310 내지 단계 S340에 따른 방법을 프로그램화하여 컴퓨터가 읽을 수 있도록 시디롬, 메모리, ROM, EEPROM 등의 기록매체에 저장시킬 수도 있다.

이상의 설명에서는 본 발명의 바람직한 실시예를 제시하여 설명하였으나, 본 발명이 반드시 이에 한정되는 것은 아니며, 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자라면 본 발명의 기술적 사상을 벗어나지 않는 범위 내에서 여러 가지 치환, 변형 및 변경할 수 있음을 쉽게 알 수 있을 것이다.

Claims (4)

1. 하나의 Writer에 다수의 Reader들이 매치된 Reliable 통신모드 시 특정 Reader의 오류로 인한 다른 노드들의 통신 지연 및 실패를 해소하기 위하여 상기 Writer가 상기 다수의 Reader들 각각에 대하여 AckNack 응답을 카운트한 후, 일정 횟수동안 AckNack 응답이 없는 Reader는 없다고 간주하고 통신을 계속해 나가는 것으로,
   상기 다수의 Reader들 각각의 상태(status)를 결정하기 위한 기준 하트비트 카운트(heart beating_count) 속성값(즉, 기준값)을 설정하고, 상기 다수의 Reader들 각각의 하트비트 카운트(heart beating_count) 속성 및 상태(status)를 초기화하는 초기화 단계와;
   새로운 데이터 전송 요청에 응답하여 상기 새로운 데이터를 상기 Writer의 데이터 저장소(History cache)에 저장하는 저장단계와;
   상기 저장된 새로운 데이터를 상기 Writer와 매치된 Reader들로 전송하되, 상기 Reader들 중 특정 Reader에 오류가 생겼다 하더라도, 다른 매치된 Reader들에게 영향 없이 연속적인 통신이 가능하도록 하는 제1단계와;
   오류가 생겼던 Reader가 다시 복구되어 통신이 가능해졌을 때 별도의 작업 없이 이어서 데이터 송수신이 가능하도록 하는 제2단계가 포함되어;
   매치된 Reader의 상황에 따라 끊김 없이 통신이 가능하도록 하되,
   상기 제1단계는
   상기 Writer가 상기 다수의 Reader들 각각에게 데이터를 전송할 때 HeartBeat 메시지를 보내는 단계와,
   상기 다수의 Reader들 각각으로부터 상기 HeartBeat 메시지의 응답인 ACKNACK 메시지가 수신되지 않는 횟수를 상기 Reader별로 카운트하여 상기 Reader별 하트비트 카운트(heart beating_count) 속성을 결정하는 단계와,
   상기 하트비트 카운트(heart beating_count) 속성이 미리 설정된 기준값과 같거나 클 경우, 해당 Reader의 상태를 INACTIVE 상태로 변경하고 없는 것처럼 동작하는 단계를 포함하고,
   상기 제2단계는
   상기 INACTIVE 상태인 Reader의 상태가 복구되어 Writer로부터 새로운 데이터와 Heartbeat 메시지를 다시 전송받는 단계와,
   상기 복구된 Reader가 상기 Writer로부터 수신한 새로운 데이터 및 Heartbeat 메시지에 대한 응답으로 ACKNACK 메시지를 송신하는 단계와,
   Writer가 INACTIVE상태인 Reader로부터 수신된 AckNack 메시지에 응답하여 해당 Reader의 상태를 다시 ACTIVE로 변경하고 통신을 이어가는 단계를 포함하는 것을 특징으로 하는 DDS 통신의 연속성 보장을 위한 방법.
2. 삭제
3. 삭제
4. 청구항 1항의 DDS 통신의 연속성 보장을 위한 방법을 실행하는 프로그램이 기록되어 컴퓨터로 읽을 수 있는 기록매체.

Images