OpenDDS의 DCPS, Discovery Service 그리고 DCPSInfoRepo

석사를 졸업한 지 4년이 지났지만... 언젠가 실무에서 다시 쓸지도 모를 0.1%의 가능성으로 DDS의 근황을 1년에 1~2번씩 찾아보곤 합니다.
석사과정 초기에 썼던 이전 글[https://leichtjoon.tistory.com/54]의 DCPSInfoRepo 내용에 살을 조금 더 붙이기 위한 후속 포스팅임

1. DCPS (Data-Centric Publish Subscribe)와 RTPS

DCPS

DCPS는 Publisher 및 Subscriber가 데이터 통신을 위한 DDS의 구성요소들을 추상화한 계층으로, 그 구성요소로는 Topic, Publisher, Subscriber, Data Reader, Data Writer, QoS, Data Sample 등이 있다. 또한 이 구성요소들을 각각의 DDS 구현체가 어떻게 구현해야 하는지를 구체적으로 정의한 것이 바로 DCPS이다.
[https://www.omg.org/spec/DDS/20140501/dds_dcps.idl]을 보면 꽤나 구체적인 인터페이스를 IDL로 정의한 것을 볼 수 있다.

RTPS

앞서 본 DCPS는 Data-Centric한 API만을 정의하고 있다. 이것은 꽤 구체적인 듯 보이지만, 실제로 DDS 구현체 간의 통신 호환성을 보장하지는 않는다. 따라서 RTPS 레이어는 Discovery Procotol(SEDP+SPDP)을 포함하여 서로 다른 DDS 구현체 간의 Publish-Subscribe가 실제로 동작하기 위하여 정의된 표준으로, RTPS 에서 사용하는 Discovery 방식으로는 (1) 설정파일을 통해 자신과 통신할 상대의 위치 정보를 미리 지정하거나 (2) Multicast를 통해 네트워크를 직접 탐색하여 찾아내는 방법이 있다.
(RTPS에는 Discovery 외에도 많은 것을 포함하고 있습니다. 지금 당장 Discovery 주제로만 간단하게 쓴 내용임을 참고 바람)

2. DCPSInfoRepo

DCPSInfoRepo는 OpenDDS-specific service로 이것이 RTPS 섹션에서 말한 "DDS 구현체 간 호환이 되지 않는 것"중 하나이다.
DCPSInfoRepo는 일종의 중앙집중형 브로커로, 각 Publisher/Subscriber은 RTPS discovery를 거치지 않아도 DCPSInfoRepo와 통신하여 discovery가 가능해진다.
이와 유사한 Impl-specific service로 RTI DDS의 Cloud Discovery Service가 있다. (당연하게도) 이것도 타 구현체와의 호환성을 제공하지 않는다.

장점

1. Multicast를 사용할 수 없는 환경에서 효율적인 discovery가 가능하다. (RTPS discovery가 이상적으로 동작하려면 Multicast의 지원이 필요하므로(
2. DCPSInfoRepo의 federation 기능을 사용하면 여러 개의 DCPSInfoRepo 서버가 논리적으로 하나의 Repo처럼 동작하여 네트워크의 확장이 가능하다. 또한 일부 서버에 장애가 발생해도 다른 서버가 그 기능을 대신 수행 가능하다.

단점

1. 서로 다른 OpenDDS 버전 간 상호운용성을 보장하지 않는다. DCPSInfoRepo 서버 및 모든 Publisher/Subscriber가 동일한 버전을 써야 한다.
2. SPoF 문제에 대비하려면 federation이 필요한데, federation은 서버를 실행하는 시점에만 설정이 가능하여 동적인 변화에 대응할 수 없다.
3. OpenDDS v4에서 deprecate 및 v5에서 완전히 제거 할 계획에 있다. 중앙 집중형 discovery를 포기한 것인지 새로운 대체 서비스를 계획중인지는 아직 알 수 없음