RTPS vs DCPS PreviousNext
Data Distribution Service (DDS) Forum > DDS FAQ >
Message/Author
Next message Okko Willeboordse  posted on Wednesday, January 02, 2008 - 09:48 am
More specifically what does DCPS add to RTPS.

They both handle subscribers, publishers and QOS,...
Next message LĂ©onard Vimond  posted on Wednesday, January 02, 2008 - 10:58 am
RTPS is a message exchange protocol, whereas the DDS defines an application level interface; that is RTPS is the underlying layer allowing DDS implementations from multiple vendors to interoperate.
A RTPS implementation is only responsible for network communications, DCPS is at user data level.
Actors in the RTPS Protocol are in one-to-one correspondence with the DDS entities, that's why names are the same.
Next message Angelo Corsaro  posted on Wednesday, January 02, 2008 - 11:45 am
Dear Okko,

The RTPS was standardized within the OMG as an interoperability wire protocol for DDS - specifically to let DDS implementations from different vendors interwork seamlessy. In a sense, you could drive the following parallel, RTPS is to DDS as GIOP is to CORBA.

Thus it is not by accident that the RTPS "supports" the key DCPS features, but it was designed to be as such.

Cheers,
Angelo

--
Angelo Corsaro, PhD
Product Marketing Manager | PrismTech
OMG DDS SIG and RTESS Co-Chair
Next message FrancescoMelillo  posted on Wednesday, January 23, 2008 - 11:06 am
HistoryCache is defined in standard OMG RTPS, while DCPS does not define clearly this entity: does an implementation of DCPS have to use HistoryCache?
Next message Niels Kortstee  posted on Wednesday, January 23, 2008 - 12:58 pm
The RTPS specification describes the protocol in terms of a "virtual machine". The only purpose of the RTPS virtual machine is to describe the protocol in a complete and un-ambigious manner. It does not require an RTPS implementation to have a 'HistoryCache' entity.

Furthermore, DCPS does not depend on RTPS. It is possible to be fully DCPS compliant, without using RTPS as the underlying transport mechanism to exchange messages over the wire. Such an implementation will not interoperate with other DCPS implementations of course.

DCPS does not define HistoryCache as a separate entity, but it does specify a History QoS policy. This policy controls the behavior of the Service when the value of an instance changes before it is finally communicated to some of its existing DataReader entities.

Best regards, Niels
Next message Anthony DaSilva Jr  posted on Friday, March 07, 2008 - 02:34 pm
Have the 3 DDS providers (PrismTech, OCI, RTI) implemented RTPS in their DDS products so that they are interoperable?

Thanks!
Next message FrancescoMelillo  posted on Sunday, March 09, 2008 - 05:16 pm
Writer RTPS receives data by DDS DataWriter (match 1:1), but DDS entity that sends data is Publisher.
Really the sequence of data transmission is: DDSDataWriter -> Publisher -> RTPSWriter, but also RTPS Writer sends data and if it matches 1:1 with DDSDataWriter, when I have 2 topic, I have 2 DDSDataWriter, 1 Publisher end 2 RTPS Writer. It's slow clear this sequence of operation, why to do match DDSDataWriter and RTPS Writer rather than Publisher and RTPS Writer?
Same consideration are valid on Subscriber side
Next message Niels Kortstee  posted on Monday, March 10, 2008 - 07:11 am
DDS DataWriters and RTPS DataWriters are bound to one single Topic and therefore to one single type, whereas Publishers are 'typeless'. Besides that, one has to consider the QoS RxO in matching the DataWriters and DataReaders.

Conceptually, communication indeed goes: DDS DataWriter --> DDS Publisher --> RTPS Writer, but this does not imply a 'slow' implementation.
Back to top
Add Your Message Here
Post:
Username: Posting Information:
This is a private posting area. Only registered users and moderators may post messages here.
Password:
Options: Post as "Anonymous"
Enable HTML code in message
Automatically activate URLs in message
Action: