what should be the DDS communication structure? -


i have 2 exiting c++ project have sender , receiver. connected udp socket connection , build through cmakefile.txt

root     |→ sender     |   |→ src     |   |→ include     |   |→ cmakefile.txt     |→ receiver     |   |→ src     |   |→ include     |   |→ cmakefile.txt     |→ cmakefile.txt     

now want change udp dds context idl

root     |→ sender     |   |→ src     |   |   |→ publisher.cpp     |   |→ include     |   |→ cmakefile.txt     |→ receiver     |   |→ src     |   |   |→ subscriber.cpp     |   |→ include     |   |→ cmakefile.txt     |→ cmakefile.txt   root     |→ sender     |   |→ src     |   |→ include     |   |→ cmakefile.txt     |→ receiver     |   |→ src     |   |→ include     |   |→ cmakefile.txt     |→ ddscom     |   |→ src     |   |   |→ publisher.cpp     |   |   |→ subscriber.cpp     |   |→ include     |   |→ cmakefile.txt     |→ cmakefile.txt 

what should structure?

project structure (source files):

the project structure present seems reasonable. in general, recommend structure of source code informed more architecture , logical structure of application, , not choice of communication mechanism.

however, there specific considerations when integrating dds project. in particular, if using idl (or xml) define dds data types application, makes sense locate files in 'common' area. dds idl compiler generate code type definition files, , generated code can compiled library, or compiled each application.

also, if using version control system (git, svn, etc), recommend idl file[s] controlled, not generated code. [there arguments control generated code too, think causes more harm good.] so, project, expect find 1 or more idl (or xml) files under ddscom/src , ddscom/include, or perhaps ddscom/idl, prefer. cmake rule can created generate type specific source code idl part of build process. guarantees generated code kept up-to-date data types, , upgrades of dds implementation.

this approach should apply regardless of dds implementation in use; example, coredx dds, opensplice, or rti.

source code structure:

regarding internal code structure (not 'directory' structure), there many ways architect application uses dds communication. dds api allows synchronous , asynchronous communication patterns.

in general data producer creates several dds entities facilitate ability write data (for example, dds::domainparticipant, dds::publisher, dds::topic, , dds::datawriter). datawriter entity supports 'write' call, , other entities provide various configuration points affect communication behavior , structure.

similarly, data consumer creates corresponding dds entities enable 'read' data (for example, dds::domainparticipant, dds::subscriber, dds::topic, , dds::datareader). datareader supports many different variants of 'read' operation provide access available data.

each of dds entities acts factory other entities, , each can configured various quality of service (qos) policy settings. these qos settings give dds rich set of configuration options impact communications. 'topic' entity defines logical grouping of data identified name, , further specifies "type" of data contained within collection.

in small project, may find easier create dds entities in place needed in application (for example, right in main() routine). alternatively, larger systems, beneficial encapsulate dds entities within component can reused among different applications.


Comments

Popular posts from this blog

javascript - Slick Slider width recalculation -

jsf - PrimeFaces Datatable - What is f:facet actually doing? -

angular2 services - Angular 2 RC 4 Http post not firing -