게시-구독(Publish-Subscribe) 패턴의 이해

분산 시스템의 설계와 구현에 있어 가장 핵심적인 난제는 시스템을 구성하는 수많은 소프트웨어 컴포넌트들 간의 복잡한 의존성을 어떻게 관리하느냐에 달려 있다. 수천, 수만 개의 노드가 실시간으로 상호작용해야 하는 국방 시스템, 자율주행 네트워크, 대규모 산업 자동화(IIoT) 환경에서, 기존의 통신 패러다임은 한계에 봉착했다. 데이터 분산 서비스(DDS, Data Distribution Service)가 채택하고 있는 게시-구독(Publish-Subscribe, 이하 Pub/Sub) 패턴은 이러한 복잡성을 해결하기 위해 고안된 아키텍처적 해법이다. 본 절에서는 DDS의 근간이 되는 Pub/Sub 패턴의 철학적 배경과 작동 원리, 그리고 이를 통해 달성할 수 있는 시스템의 유연성과 확장성에 대해 심도 있게 논의한다.

1. 분산 시스템의 통신 패러다임 진화와 결합도(Coupling)의 문제

소프트웨어 아키텍처의 역사는 결합도(Coupling)를 낮추기 위한 투쟁의 역사라 해도 과언이 아니다. 결합도란 두 개 이상의 모듈이나 컴포넌트가 상호 의존하는 정도를 의미한다. 강한 결합(Tight Coupling)은 시스템의 한 부분을 변경할 때 다른 부분에도 연쇄적인 수정이 필요하게 만들며, 이는 유지보수의 악몽과 시스템 확장성의 저하를 초래한다.

1.1 직접 호출과 동기 통신의 한계

초기의 분산 시스템은 단일 컴퓨터 내에서의 프로그래밍 모델을 네트워크로 확장하려는 시도에서 출발했다. 원격 프로시저 호출(RPC, Remote Procedure Call)이나 CORBA(Common Object Request Broker Architecture), DCOM(Distributed Component Object Model)과 같은 기술들은 원격지에 있는 함수나 객체의 메서드를 마치 로컬에 있는 것처럼 호출(Call)하는 데 주력했다. 이러한 방식은 ‘요청-응답(Request-Response)’ 모델을 기반으로 하며, 다음과 같은 특징으로 인해 대규모 실시간 시스템에는 부적합한 측면이 있다.1

동기적 차단(Synchronous Blocking): 호출자(Caller/Client)는 피호출자(Callee/Server)가 작업을 완료하고 응답을 보낼 때까지 대기해야 한다. 이는 네트워크 지연이나 서버의 부하가 클라이언트의 성능 저하로 직결됨을 의미한다.
주소 종속성(Address Dependency): 클라이언트는 서버의 정확한 네트워크 위치(IP 주소, 포트 번호, 객체 참조 등)를 알고 있어야 한다. 서버의 위치가 바뀌거나 새로운 서버가 추가될 때마다 클라이언트의 설정이나 코드를 변경해야 하는 경직성을 낳는다.2
일대일(Point-to-Point) 구조의 경직성: 다수의 클라이언트가 다수의 서버와 통신해야 하는 N:M 상황에서, 각 연결을 개별적으로 관리해야 하므로 연결 복잡도가 기하급수적으로 증가한다.

1.2 비동기 메시징의 대두

이러한 한계를 극복하기 위해 메시지 지향 미들웨어(MOM, Message-Oriented Middleware)가 등장했다. 메시지 큐(Message Queue)와 같은 기술은 송신자와 수신자 사이에 버퍼를 두어 비동기 통신을 지원했다. 그러나 전통적인 메시지 큐 시스템 역시 여전히 송신자가 메시지를 누구에게 보낼지(Target Queue)를 명시해야 하는 경우가 많았으며, 동적인 네트워크 변화에 유연하게 대처하기에는 구조적 한계가 존재했다.3

1.3 게시-구독 모델의 혁신

Pub/Sub 패턴은 통신의 주체를 ’정보 생산자(Publisher)’와 ’정보 소비자(Subscriber)’로 명확히 분리하고, 이들 사이에 ’토픽(Topic)’이라는 논리적 채널을 둠으로써 직접적인 의존성을 제거했다. Eugster 등(2003)의 기념비적인 연구 “The Many Faces of Publish/Subscribe“에서 지적하듯, 이 패턴은 분산 시스템의 상호작용을 느슨한 결합(Loose Coupling) 상태로 전환시켜 동적인 대규모 네트워크 환경에 적합한 유연성을 제공한다.1 DDS는 이러한 Pub/Sub 모델을 데이터 중심(Data-Centric)으로 고도화하여 표준화한 기술이다.

2. 게시-구독 패턴의 핵심 이론: 3차원 결합 해제(Decoupling)

DDS와 같은 현대적인 Pub/Sub 미들웨어가 제공하는 강력한 확장성과 유연성은 근본적으로 공간(Space), 시간(Time), **동기화(Synchronization)**라는 세 가지 차원에서의 결합 해제(Decoupling)에서 기인한다.1 이 세 가지 차원의 분리는 시스템 설계자에게 물리적 제약을 뛰어넘는 추상화된 통신 환경을 제공한다.

2.1 공간적 결합 해제 (Space Decoupling): 상호 인지 불필요성

공간적 결합 해제는 통신 참여자들이 서로를 알 필요가 없음을 의미하며, ’참조 결합 해제(Referential Decoupling)’라고도 불린다.

익명성(Anonymity): 게시자(Publisher)는 데이터를 누가 소비할지 알지 못한 채 시스템(정확히는 글로벌 데이터 공간)에 데이터를 투척한다. 구독자(Subscriber) 역시 데이터가 어떤 특정 노드에서 생성되었는지, 혹은 몇 개의 노드가 데이터를 보내는지 알 필요 없이 자신이 관심 있는 ’주제(Topic)’만을 선언한다.6
토폴로지의 유동성: 이러한 익명성은 시스템 구성을 매우 유연하게 만든다. 예를 들어, 함정 전투 시스템에서 새로운 센서(게시자)가 추가되더라도 기존의 무기 통제 시스템(구독자)을 재설정하거나 재컴파일할 필요가 없다. 미들웨어가 자동으로 새로운 데이터 소스를 감지하고 연결하기 때문이다. 이는 ‘플러그 앤 플레이(Plug-and-Play)’ 기능을 가능케 하는 핵심 원리이다.2

2.2 시간적 결합 해제 (Time Decoupling): 생명주기의 독립성

시간적 결합 해제는 데이터의 생산 시점과 소비 시점이 반드시 일치할 필요가 없음을 의미한다.

비동기적 참여: 게시자가 메시지를 발행하는 순간에 구독자가 네트워크에 연결되어 있지 않아도 무방하다. 반대로 구독자가 오프라인 상태일 때 발행된 데이터도, 구독자가 다시 온라인이 되었을 때 전달받을 수 있어야 한다.5
DDS의 내구성(Durability): 일반적인 소켓 통신에서는 수신자가 연결되어 있지 않으면 데이터는 소실된다. 그러나 DDS는 DURABILITY QoS(Quality of Service) 정책을 통해 미들웨어 차원에서 데이터를 저장하고 관리한다. 늦게 참여한(Late-joining) 구독자에게 과거의 데이터를 전달하거나, 시스템 재부팅 후에도 데이터의 영속성을 보장함으로써 시간의 제약을 극복한다.8 이는 간헐적인 네트워크 연결이 빈번한 모바일 환경이나 위성 통신 환경에서 필수적인 기능이다.

2.3 동기화 결합 해제 (Synchronization Decoupling): 제어 흐름의 분리

동기화 결합 해제는 메인 제어 흐름(Control Flow)이 통신으로 인해 차단(Block)되지 않음을 의미한다.

비차단(Non-blocking) 발행: 게시자는 데이터를 발행하는 동안 구독자의 수신 여부나 처리 완료를 기다리지 않는다. 게시자는 자신의 주기대로 데이터를 쏟아내고, 즉시 자신의 로직으로 복귀한다. 이는 고속의 센서 데이터 처리에 있어 필수적이다.4
비동기 알림(Asynchronous Notification): 구독자 역시 데이터를 기다리며 무한정 대기하지 않는다. 구독자는 자신의 업무를 수행하다가, 관심 데이터가 도착했을 때 미들웨어로부터 ’인터럽트’와 유사한 방식의 콜백(Callback)이나 리스너(Listener) 호출을 받아 데이터를 처리한다.9 DDS는 Listener 패턴 외에도 WaitSet을 이용한 비동기 대기 방식 등을 제공하여 개발자가 애플리케이션의 동시성 모델을 유연하게 설계할 수 있도록 지원한다.

이 세 가지 결합 해제의 조합은 시스템의 전체적인 **확장성(Scalability)**을 극적으로 향상시킨다.10 수천 개의 노드가 얽혀 있는 복잡한 시스템에서도 각 노드는 독립적으로 동작할 수 있으며, 네트워크 병목이나 특정 노드의 장애가 전체 시스템으로 전파되는 것을 방지한다.

3. 구독 모델의 분류와 필터링 메커니즘

Pub/Sub 시스템에서 구독자가 자신이 원하는 정보를 표현하는 방식은 시스템의 효율성과 표현력(Expressiveness)을 결정짓는 중요한 요소이다. DDS는 전통적인 토픽 기반 모델을 넘어 내용 기반 및 타입 기반 모델의 장점을 흡수하여 강력한 데이터 중심 필터링을 제공한다.

3.1 토픽 기반 (Topic-Based) 구독

가장 보편적인 형태로, 메시지를 ’토픽’이라는 문자열 이름으로 식별한다.

원리: 게시자는 “Weather/Temperature“라는 토픽으로 데이터를 발행하고, 구독자는 동일한 토픽 이름을 구독함으로써 연결된다.6
장점: 구현이 단순하고, 매칭 알고리즘이 효율적이다. 멀티캐스트 그룹 매핑이 용이하여 네트워크 효율성이 높다.
DDS의 접근: DDS는 토픽 이름을 기본 식별자로 사용하되, 여기에 강력한 타입 정보를 결합한다.

3.2 내용 기반 (Content-Based) 구독

토픽 이름뿐만 아니라, 데이터의 실제 내용(속성 값)을 조건으로 필터링한다.

원리: 구독자는 “토픽이 ’Stock/Samsung’이면서, ‘Price’ 필드의 값이 80,000원 이상인 데이터“와 같이 구체적인 조건을 명시한다(Predicates).1
장점: 구독자는 불필요한 데이터를 수신하지 않아도 되므로, 애플리케이션 레벨의 부하가 감소한다.
DDS의 접근: DDS는 ContentFilteredTopic을 제공하여 SQL 구문(e.g., WHERE x > 10 AND y < 5)을 이용한 정교한 필터링을 지원한다.11 중요한 점은, 스마트한 DDS 구현체들은 이 필터 정보를 게시자 측(Writer side)으로 전달하여, 게시자가 조건에 맞지 않는 데이터는 아예 네트워크로 보내지 않도록 최적화한다는 것이다(Writer-side Filtering).

3.3 타입 기반 (Type-Based) 구독

데이터의 구조나 객체 타입(Type) 자체를 구독의 기준으로 삼는다.

원리: 메시지를 일련의 바이트 스트림이 아닌, 정의된 구조체나 객체로 취급한다. 구독자는 특정 타입(예: struct VehiclePosition)의 모든 인스턴스를 구독하려 한다.7
장점: 프로그래밍 언어의 타입 시스템과 통합되어 컴파일 타임에 오류를 검출할 수 있다(Type Safety).
DDS의 접근: DDS는 OMG IDL(Interface Definition Language)을 사용하여 데이터 타입을 엄격하게 정의한다.12 “토픽 이름“과 “데이터 타입“이 모두 일치해야 통신이 성립되므로, 서로 다른 구조의 데이터를 같은 이름으로 보내서 발생하는 런타임 오류를 원천 차단한다. 이는 시스템 통합(Integration) 단계에서 발생할 수 있는 데이터 불일치 비용을 획기적으로 줄여준다.13

구독 모델 유형	필터링 기준	DDS 적용 (DCPS)	장점 및 특징
Topic-Based	주제명 (문자열)	`Topic` (Name)	단순성, 빠른 매칭, 멀티캐스트 매핑 용이
Content-Based	데이터 값 (속성)	`ContentFilteredTopic` (SQL-like)	대역폭 절약, 수신측 부하 감소, 송신측 필터링 가능
Type-Based	데이터 구조 (Schema)	`TypeSupport` (IDL)	타입 안전성 보장, 이기종 간 데이터 호환성, 컴파일 타임 검증

4. 아키텍처 비교 심층 분석: 클라이언트-서버(C/S) 대 게시-구독(P/S)

Pub/Sub 패턴의 가치는 기존의 지배적인 아키텍처인 클라이언트-서버 모델과 비교했을 때 더욱 명확해진다. 웹 서비스나 엔터프라이즈 IT 시스템에서 널리 쓰이는 C/S 모델은 중앙 집중적인 데이터 관리에는 유리하지만, 실시간성과 확장성이 요구되는 엣지 컴퓨팅이나 IoT 환경에서는 구조적 한계를 드러낸다.

4.1 토폴로지와 확장성 (Topology and Scalability)

클라이언트-서버: 스타(Star) 형 토폴로지를 갖는다. 모든 클라이언트는 중앙 서버에 연결되어야 한다. 클라이언트 수가 증가하면 서버에 병목(Bottleneck)이 발생하며, 서버의 성능을 높이는 수직적 확장(Scale-up)에는 한계가 있다.14
게시-구독 (DDS): 메시/피어(Mesh/Peer-to-Peer) 형 토폴로지를 형성한다. 중앙의 병목 지점이 없으므로 노드가 추가되더라도 전체 네트워크 대역폭이 허용하는 한 무한에 가까운 수평적 확장(Scale-out)이 가능하다.16 특히 DDS는 멀티캐스트(Multicast)를 활용하여, 하나의 데이터를 백만 명의 구독자에게 보내더라도 게시자의 부하가 거의 증가하지 않는 효율성을 자랑한다.18

4.2 상태 관리와 발견 (State Management and Discovery)

클라이언트-서버: 상태(State)는 서버에 집중된다. 클라이언트는 수동적(Passive)이다. 서버의 주소가 변경되면 모든 클라이언트를 재설정해야 한다(Static Configuration).
게시-구독 (DDS): 상태는 ’글로벌 데이터 공간’에 분산 저장된다. 참여자들은 동적 발견(Dynamic Discovery) 메커니즘을 통해 런타임에 서로를 찾는다.2 DDS는 SPDP(Simple Participant Discovery Protocol)와 같은 프로토콜을 사용하여, 네트워크에 전원을 켜고 연결하는 즉시 별도의 설정 없이 통신망에 합류할 수 있다. 이는 전장이나 재난 현장과 같이 인프라가 수시로 변하는 환경에서 결정적인 차이를 만든다.19

4.3 통신 흐름과 제어 (Communication Flow)

클라이언트-서버 (Polling): 클라이언트가 데이터 변경 여부를 확인하기 위해 서버에 주기적으로 요청을 보내야 한다. 주기가 짧으면 서버 부하가 커지고, 길면 실시간성이 떨어진다.
게시-구독 (Event-driven): 데이터가 변경되는 ’사건(Event)’이 발생했을 때만 통신이 일어난다. 이는 불필요한 트래픽을 제거하고(Quiet Network), 변경 사항을 가장 빠르게 전파할 수 있는 구조이다.20

5. 중개자의 형태: 중앙 집중형 브로커 vs. 분산형 P2P

Pub/Sub 패턴을 구현하는 방식은 크게 ‘중앙 집중형 브로커(Broker)’ 방식과 ‘브로커리스(Broker-less) P2P’ 방식으로 나뉜다. DDS의 고유한 특징을 이해하기 위해서는 이 차이를 명확히 구분해야 한다.

5.1 중앙 집중형 브로커 (e.g., JMS, MQTT, Kafka)

대부분의 엔터프라이즈 Pub/Sub 시스템은 중앙에 메시지 브로커 서버를 둔다.

작동: 게시자는 브로커에게 메시지를 보내고, 브로커가 이를 구독자에게 전달한다. ‘허브 앤 스포크(Hub-and-Spoke)’ 구조이다.21
장점: 클라이언트 구현이 단순해지며, 브로커가 메시지 저장 및 상태 관리를 전담하므로 관리가 용이하다.
단점 (DDS 관점에서의 비판):
단일 실패 지점 (SPoF): 브로커가 다운되면 전체 통신이 마비된다.
지연 시간 (Latency): 메시지가 반드시 브로커를 거쳐야 하므로 ‘2-Hop’ 통신이 발생하여 지연 시간이 증가한다.
병목 현상: 모든 트래픽이 브로커로 집중되므로 대규모 데이터 전송 시 브로커가 병목이 된다.22

5.2 분산형 P2P (e.g., DDS, RTPS)

DDS는 기본적으로 브로커가 없는(Broker-less) 아키텍처를 채택하고 있다.

작동: 미들웨어 라이브러리가 각 애플리케이션에 내장(Embedded)되어 동작한다. 통신은 게시자와 구독자 간에 직접(Direct) 이루어진다.17
장점:
최저 지연 시간: 중간 경유지가 없는 ‘1-Hop’ 통신이므로 물리적 한계에 가까운 실시간성을 제공한다.
무한한 확장성: 중앙 서버의 용량 제한이 없다.
고신뢰성: 일부 노드가 파괴되어도 나머지 노드 간의 통신은 유지된다(Fault Tolerance).
구현: DDS 표준 와이어 프로토콜인 RTPS(Real-Time Publish-Subscribe)는 UDP/IP 위에서 신뢰성, 순서 보장, 단편화 등을 직접 처리하여 P2P 통신의 복잡성을 추상화한다.24

Note: 최근 일부 DDS 구현체나 확장 표준(예: ROS 2의 Discovery Server)에서는, 대규모 네트워크에서의 발견 트래픽을 줄이거나 방화벽/NAT 투과를 위해 선택적으로 브로커와 유사한 ’Discovery Server’나 ’Routing Service’를 도입하기도 한다. 그러나 데이터 경로(Data Path)만큼은 여전히 P2P를 지향하는 것이 원칙이다.19

6. 데이터 중심(Data-Centric) 사상으로의 도약

일반적인 Pub/Sub 시스템(예: JMS)은 ’메시지(Message)’를 전달하는 데 초점을 맞춘다. 즉, “A가 B라는 내용을 보냈다“는 행위(Event) 자체가 중요하다. 그러나 DDS는 여기서 한 걸음 더 나아가 데이터 중심 게시-구독(DCPS: Data-Centric Publish-Subscribe) 모델을 정의한다.12

6.1 메시지 중심(Message-Centric) vs. 데이터 중심(Data-Centric)

메시지 중심: “주식 정보를 보낸다.” -> 수신자는 받은 메시지를 해석하고, 자신의 내부 데이터베이스를 업데이트해야 한다. 메시지는 일회성이고 휘발성이다.
데이터 중심: “삼성전자의 주가는 80,000원이다.” -> DDS 미들웨어 자체가 분산 데이터베이스처럼 동작한다. 미들웨어는 “삼성전자“라는 키(Key)를 가진 데이터 객체의 상태(State)를 80,000원으로 갱신하고, 이 변경 사항을 구독자의 로컬 캐시에 동기화한다.23

6.2 글로벌 데이터 공간(Global Data Space)의 서막

DCPS 모델에서 게시자와 구독자는 단순히 메시지를 주고받는 것이 아니라, 가상의 공유 메모리 공간인 ’글로벌 데이터 공간’을 통해 데이터를 공유한다.

데이터 객체와 키(Key): DDS는 토픽 내에서 ‘키(Key)’ 필드를 통해 개별 데이터 인스턴스(Instance)를 구분한다(마치 관계형 데이터베이스의 Primary Key와 같다).27 예를 들어, ’항공기 위치’라는 토픽에서 ’Flight ID’를 키로 지정하면, 수천 대 항공기의 위치를 각각 독립적인 인스턴스로 관리할 수 있다.
생명주기 관리: 미들웨어는 데이터의 생성(Register), 갱신(Write), 삭제(Dispose), 그리고 비정상 종료에 의한 소실(Unregister) 등 데이터 인스턴스의 전체 생명주기를 관리하고 이를 구독자에게 전파한다.29

이러한 데이터 중심 사상은 개발자가 복잡한 통신 코드를 작성하는 대신, “데이터를 어떻게 정의하고 관리할 것인가“에 집중하게 만든다. 이것이 바로 DDS가 단순한 메시징 라이브러리를 넘어, ’데이터를 위한 미들웨어’로 불리는 이유이다.

7. 품질 서비스(QoS) 계약: 결합 해제의 보완재

마지막으로, Pub/Sub 패턴에서 통신 당사자들이 서로를 모른다는 것(Decoupling)은 한편으로는 위험 요인이 될 수 있다. “내 데이터를 누가 받기는 하는 것인가?”, “네트워크가 끊기면 어떻게 되는가?“와 같은 불확실성이 존재하기 때문이다.

DDS는 이 문제를 해결하기 위해 광범위하고 세밀한 QoS(Quality of Service) 정책을 도입했다. QoS는 게시자와 구독자 간의 ‘계약(Contract)’ 역할을 한다.11

게시자는 “나는 데이터를 확실하게(Reliable) 보내겠다“고 선언한다.
구독자는 “나는 데이터를 반드시 순서대로(Ordered) 받아야 한다“고 요구한다.
미들웨어는 연결 시점에 양측의 QoS를 비교(Request vs. Offered)하여 호환될 때만 통신을 허용한다(RxO: Request/Offered Semantics).24

이는 결합 해제로 인해 느슨해진 연결에 엔지니어링 수준의 신뢰성과 예측 가능성을 부여하는 장치이며, DDS가 미션 크리티컬 분야에서 독보적인 지위를 차지하게 된 결정적인 요인 중 하나이다.

8. 요약 및 시사점

게시-구독(Publish-Subscribe) 패턴은 단순한 기술적 선택이 아니라, 복잡해지는 분산 시스템 환경에서 살아남기 위한 아키텍처적 진화의 산물이다. 공간, 시간, 동기화의 3차원 결합 해제를 통해 시스템은 유연성과 확장성을 얻었고, DDS는 여기에 ’데이터 중심(Data-Centric)’이라는 철학과 ’P2P’라는 구조, 그리고 ’QoS’라는 통제 수단을 결합하여 완성형 미들웨어로 거듭났다.

기존의 클라이언트-서버 모델이 ’중앙의 지능’에 의존했다면, DDS의 Pub/Sub 모델은 ’분산된 지능’과 ’공유된 데이터’를 지향한다. 다음 절인 **“2.2 글로벌 데이터 공간(Global Data Space) 개념”**에서는 이러한 아키텍처가 만들어내는 가상의 데이터 공유 환경이 실제로 어떻게 구현되고 작동하는지, 그리고 이것이 개발자에게 어떤 추상화를 제공하는지 구체적으로 살펴볼 것이다. 1

9. 참고 자료

The Many Faces of Publish/Subscribe - Institute for Computing and Information Sciences, http://www.cs.ru.nl/~marko/onderwijs/oss/eugster-al_publish-subscribe.pdf
What can DDS do for You? - Twin Oaks Computing, Inc, https://www.twinoakscomputing.com/wp/CoreDX_DDS_Why_Use_DDS.pdf
The Many Faces of Publish/Subscribe - Software Systems Laboratory, http://systems.cs.columbia.edu/ds2-class/papers/eugster-pubsub.pdf
Messaging Pattern: Publish-Subscribe - A. Rothuis, https://www.arothuis.nl/posts/messaging-pub-sub/
Publish-Subscribe Systems - Ohohlfeld.com - Oliver Hohlfeld, http://downloads.ohohlfeld.com/talks/hohlfeld_schroeder-publish_subscribe_systems-dsmware_eurecom2007.pdf
What is Pub/Sub Messaging? - AWS, https://aws.amazon.com/what-is/pub-sub-messaging/
Type-Based Publish/Subscribe - Infoscience, https://infoscience.epfl.ch/server/api/core/bitstreams/4c7cfb2b-d928-44ea-8576-768e71c451da/content
1. Quality of Service — The Data Distribution Service Tutorial, https://download.zettascale.online/www/docs/Vortex/html/ospl/DDSTutorial/qos.html
OMG Data-Distribution Service: Architectural Overview, https://d2vkrkwbbxbylk.cloudfront.net/sites/default/files/DDS_Architectural_Overview.pdf
Publish–subscribe pattern - Wikipedia, https://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern
Evaluating the Performance of Publish/Subscribe Platforms for Information Management in Distributed Real-time and Embedded Systems - DDS Foundation, https://www.dds-foundation.org/sites/default/files/Evaluating_Performance_Publish_Subscribe_Platforms.pdf
About the Data Distribution Service Specification Version 1.4, https://www.omg.org/spec/DDS/1.4/About-DDS
Using DDS to Unlock the Power of TSN - RTI, https://www.rti.com/hubfs/_Collateral/Technical_Insight/rti-technical-insight-dds-tsn.pdf
Difference Between Client /Server and Distributed DBMS - GeeksforGeeks, https://www.geeksforgeeks.org/computer-networks/difference-between-client-server-and-distributed-dbms/
What Are Distributed Architectures: 4 Types & Key Components | Estuary, https://estuary.dev/blog/distributed-architecture/
Architectural overview of Pub/Sub - Google Cloud Documentation, https://docs.cloud.google.com/pubsub/architecture
Client-Server vs. Peer-to-Peer Architecture: A DDS Perspective - Pavel Pohanka, https://pavelpohanka.cz/en/blog/client-server-vs-peer-to-peer-architecture-a-dds-perspective/
Why DDS - eProsima, https://www.eprosima.com/developer-resources/why-dds
Using Fast DDS Discovery Server as discovery protocol [community-contributed] — ROS 2 Documentation: Rolling documentation, https://docs.ros.org/en/rolling/Tutorials/Advanced/Discovery-Server/Discovery-Server.html
The Difference Between Client-Server and Publisher-Subscriber - Nordic APIs, https://nordicapis.com/the-difference-between-client-server-and-publisher-subscriber/
What is Pub/Sub? The Publish/Subscribe model explained - Ably Realtime, https://ably.com/topic/pub-sub
Introduction to DDS - eProsima, https://www.eprosima.com/developer-resources/whitepapers/dds
What is DDS? - DDS Foundation, https://www.dds-foundation.org/what-is-dds-3/
The Real-time Publish-Subscribe Protocol (RTPS) DDS Interoperability Wire Protocol Specification - Object Management Group (OMG), https://www.omg.org/spec/DDSI-RTPS/2.2/PDF
Data Distribution Service - Wikipedia, https://en.wikipedia.org/wiki/Data_Distribution_Service
A Comparison and Mapping of Data Distribution Service (DDS) and Java Message Service (JMS) - DDS Foundation, https://www.dds-foundation.org/sites/default/files/Comparison_of_DDS_and_JMS.pdf
3.5.1. Topics, keys and instances - eProsima Fast DDS, https://fast-dds.docs.eprosima.com/en/3.x/fastdds/dds_layer/topic/instances.html
1. Keys and Instances — RTI Connext Getting Started documentation - RTI Community, https://community.rti.com/static/documentation/connext-dds/current/doc/manuals/connext_dds_professional/getting_started_guide/csharp/intro_keys_instances.html
Data Distribution Service (DDS) - Object Management Group, https://www.omg.org/spec/DDS/1.4/PDF/changebar
Data Distribution Service for Real-Time Systems Specification - Object Management Group (OMG), https://www.omg.org/spec/DDS/1.1/PDF/
1.1.1. The DCPS conceptual model - eProsima Fast DDS, https://fast-dds.docs.eprosima.com/en/3.x/fastdds/getting_started/definitions.html
DataWriters/Publishers and DataReaders/Subscribers, https://community.rti.com/static/documentation/connext-dds/current/doc/manuals/connext_dds_professional/users_manual/users_manual/DataWriters_Publishers_and_DataReaders.htm
Data-Centric Programming Best Practices: - RTI, https://www.rti.com/hubfs/docs/DDS_Best_Practices_WP.pdf