ddsdcps文档_dcps - CSDN文库

rtps

需积分: 10 67 浏览量更新于2023-12-21 收藏 1.17MB PDF 举报

身份认证购VIP最低享 7 折!

领优惠券(最高得80元）

资源详情

资源推荐

4 Data Distribution Service, v1.4

The operation <parameter> can contain the modifier “in,” “out,” or “inout” ahead of the parameter name. If this modifier is

omitted, it is implied that the parameter is an “in” parameter.

In some cases the operation parameters or return value(s) are a collection with elements of a given <type>. This is indicated

with the notation “<type> [ ].” This notation does not imply that it will be implemented as an array. The actual implementation

is defined by the PSM: it may end up being mapped to a sequence, a list, or other kind of collection.

For example, the class named ‘MyClass’ below has a single attribute, named ‘my_attribute’ of type ‘long’ and a single

operation ‘my_operation’ that returns a long. The operation takes four parameters. The first, ‘param1,’ is an output parameter

of type long; the second, ‘param2,’ an input-output parameter of type long; the third, ‘param3,’ is an input parameter (the “in”

modifier is implied by omission) of type long; and the fourth, ‘param4,’ is also an input parameter of type collection of longs.

At the PIM level we have modeled errors as operation return codes typed ReturnCode_t. Each PSM may map these to either

return codes or exceptions. The complete list of return codes is indicated below.

attributes

... ...

operations

... ...

Myclass

attributes

my_attribute long

operations

my_operation long

out: param1 long

inout: param2 long

param3 long

in: param4 long

2. That is, a collection where the type of each element is ‘long’.

Data Distribution Service, v1.4 5

Any operation with return type ReturnCode_t may return OK, ERROR, or ILLEGAL_OPERATION. Any operation that

takes an input parameter may additionally return BAD_PARAMETER. Any operation on an object created from any of the

factories may additionally return ALREADY_DELETED. Any operation that is stated as optional may additionally return

UNSUPPORTED. The return codes OK, ERROR, ILLEGAL_OPERATION, ALREADY_DELETED, UNSUPPORTED, and

BAD_PARAMETER are the standard return codes and the specification won’t mention them explicitly for each operation.

Operations that may return any of the additional (non-standard) error codes above will state so explicitly.

It is an error for an application to use an Entity that has already been deleted by means of the corresponding delete operation on

the factory. If an application does this, the result is unspecified and will depend on the implementation and the PSM. In the

cases where the implementation can detect the use of a deleted entity, the operation should fail and return

ALREADY_DELETED.

2.2.1.2 Conceptual Outline

2.2.1.2.1 Overview

Return codes

OK Successful return.

ERROR Generic, unspecified error.

BAD_PARAMETER Illegal parameter value.

UNSUPPORTED Unsupported operation. Can only be returned by operations

that are optional.

ALREADY_DELETED The object target of this operation has already been

deleted.

OUT_OF_RESOURCES Service ran out of the resources needed to complete the

operation.

NOT_ENABLED Operation invoked on an Entity that is not yet enabled.

IMMUTABLE_POLICY Application attempted to modify an immutable QosPolicy.

INCONSISTENT_POLICY Application specified a set of policies that are not

consistent with each other.

PRECONDITION_NOT_MET A pre-condition for the operation was not met.

TIMEOUT The operation timed out.

ILLEGAL_OPERATION An operation was invoked on an inappropriate object or at

an inappropriate time (as determined by policies set by the

specification or the Service implementation). There is no

precondition that could be changed to make the operation

succeed.

NO_DATA Indicates a transient situation where the operation did not

return any data but there is no inherent error.

6 Data Distribution Service, v1.4

Figure 2.1 - Overview

Information flows with the aid of the following constructs

: Publisher and DataWriter on the sending side; Subscriber and

DataReader on the receiving side.

• A Publisher is an object responsible for data distribution. It may publish data of different data types. A DataWriter acts

as a typed

accessor to a publisher. The DataWriter is the object the application must use to communicate to a publisher

the existence and value of data-objects of a given type. When data-object values have been communicated to the

publisher through the appropriate data-writer, it is the publisher’s responsibility to perform the distribution (the

publisher will do this according to its own QoS, or the QoS attached to the corresponding data-writer). A publication is

defined by the association of a data-writer to a publisher. This association expresses the intent of the application to

publish the data described by the data-writer in the context provided by the publisher.

• A Subscriber is an object responsible for receiving published data and making it available (according to the

Subscriber’s QoS) to the receiving application. It may receive and dispatch data of different specified types. To access

the received data, the application must use a typed DataReader attached to the subscriber. Thus, a subscription is

defined by the association of a data-reader with a subscriber. This association expresses the intent of the application to

subscribe to the data described by the data-reader in the context provided by the subscriber.

Top ic objects conceptually fit between publications and subscriptions. Publications must be known in such a way that

subscriptions can refer to them unambiguously. A Topic is meant to fulfill that purpose: it associates a name (unique in the

domain

), a data-type, and QoS related to the data itself. In addition to the topic QoS, the QoS of the DataWriter associated

3. All those constructs are local to the application part. Actually they play the role of proxies to the service.

4. 'typed' means that each DataWriter object is dedicated to one application data-type.

5. Broadly speaking, a domain represents the set of applications that are communicating with each other. This concept is defined

more precisely in 2.2.1.2.2, Overall Conceptual Model and 2.2.2.2.1, DomainParticipant Class.

Data Distribution Service, v1.4 7

with that Topic and the QoS of the Publisher associated to the DataWriter control the behavior on the publisher’s side, while

the corresponding Topic, DataReader, and Subscriber QoS control the behavior on the subscriber’s side.

When an application wishes to publish data of a given type, it must create a Publisher (or reuse an already created one) and a

DataWriter with all the characteristics of the desired publication. Similarly, when an application wishes to receive data, it must

create a Subscriber (or reuse an already created one) and a DataReader to define the subscription.

2.2.1.2.2 Overall Conceptual Model

The overall conceptual model is shown in Figure 2.2. Notice that all the main communication objects (the specializations of

Entity) follow unified patterns of:

• Supporting QoS (made up of several QosPolicy); QoS provides a generic mechanism for the application to control the

behavior of the Service and tailor it to its needs. Each Entity supports its own specialized kind of QoS policies. The

complete list of QoS policies and their meaning is described in 2.2.3, Supported QoS.

• Accepting a Listener

; listeners provide a generic mechanism for the middleware to notify the application of relevant

asynchronous events, such as arrival of data corresponding to a subscription, violation of a QoS setting, etc. Each

DCPS entity supports its own specialized kind of listener. Listeners are related to changes in status conditions. This

relationship is described in 2.2.4, Listeners, Conditions, and Wait-sets.

• Accepting a StatusCondition (and a set of ReadCondition objects for the DataReader); conditions (in conjunction with

WaitSet objects) provide support for an alternate communication style between the middleware and the application (i.e.,

wait-based rather than notification-based). The complete set of status conditions is described in 2.2.4, Listeners,

Conditions, and Wait-sets.

All these DCPS entities are attached to a DomainParticipant. A domain participant represents the local membership of the

application in a domain. A domain is a distributed concept that links all the applications able to communicate with each other.

It represents a communication plane: only the publishers and the subscribers attached to the same domain may interact.

DomainEntity is an intermediate object whose only purpose is to state that a DomainParticipant cannot contain other domain

participants.

6. This specification made the choice of allowing the attachment of only one Listener per entity (instead of a list of them). The

reason for that choice is that this allows a much simpler (and, thus, more efficient) implementation as far as the middleware is

concerned. Moreover, if it were required, implementing a listener that, when triggered, triggers in return attached 'sub-listeners,'

can be easily done by the application.

剩余179页未读，继续阅读

heihei36

粉丝: 13
资源: 10

会员权益专享

"DDS DCPS文档版本1.4发布：标准规范与机器可读文件"

会员权益专享

最新资源

"DDS DCPS文档版本1.4发布：标准规范与机器可读文件"

RTI DDS 入门说明文档

DDS数据分发接口模块开发文档.docx

opendds开发文档 （有道翻译后）

OpenDDS::DCPS::RcObject::RcObject”: 无法访问 private 成员(在“OpenDDS::DCPS::RcObjectS_Dcps

opendds 中文文档

OpenDDS::DCPS::TransportImpl_rch怎么赋值

使用OpenDDS::DCPS::TransportImpl_rch需要包含什么头文件？

opendds获取ini配置文件Transport的配置信息并给OpenDDS::DCPS::TransportImpl_rch transport_impl 赋值，TheTransportRegistry的用法需要包含的头文件

OpenDDS实现RTPS的C++例子

opendds获取配置文件Transport的配置信息并给OpenDDS::DCPS::TransportImpl_rch transport_impl 赋值

opendds3.20的TransportRegistry的代码实现

error C2248: “OpenDDS::DCPS::RcObject::RcObject”: 无法访问 private 成员(在“OpenDDS::DCPS::RcObject”类中声明)

cyclone dds supports currently the following language bindings for the dcps

python实现dds服务

dds数据分发服务中的DCPS模型有哪些元素，分别代表什么

opendds使用multicast传输数据时，解决内存一直增长问题的实现代码

opendds使用方法

c++ 编写opendds多线程

opendds中文教程

opendds配置vs

会员权益专享

最新资源

opendds开发文档（有道翻译后）