Connext DDS + Android Reply

Android is the dominant operating system in mobile, for both phones and tablets. As mobile eats away at the traditional desktop/laptop market, Android rivals Windows, Linux and Mac OSX as an operating system of major importance. Fueled by its application development eco system, Android is recruiting new developers at an unprecedented rate and those developers are innovating, creating novel application and taking Android into new places.

If we look past the Android Application Framework, we see an operating system that fits very well with the needs of embedded systems. Increasingly Android is being applied to such opportunities. So Android is becoming relevant, not only to the consumer aspect of the Internet of Things, but also to the industrial aspect. We expect to see a breakthrough in embedded device to cloud connectivity further driving new embedded applications.

To address the needs of developers, we have provided our distributed applications platform, RTI Connext DDS, on Android enabling the creation of publish and subscribe applications for the Industrial Internet of Things.

30dayFree trial rti connext dds professional

Scaling Down: DDS into Sensor Networks Reply

london connext conference rti EMEA 2014

Connext Conference 2014 is taking place 8-9 October in London. To learn more or RSVP, visit

Below is an abstract of a talk that RTI plans to have available at the RTI Connext Users Group meeting, to be held in London next week (

RTI is a firm believer in the Data Centric model of Pub/Sub. Even in places we can’t yet reach.

When it’s a question of scale, customers of RTI generally ask about the macro abilities of Connext DDS: how far up, or how far out RTI Connext DDS will scale, looking to support thousands, tens of thousands or even millions of discrete points-of-presence across their systems of systems. Sometimes this happens at design time, sometimes this happens after deployment.

On the other hand, sometimes it’s scaling downwards. RTI Connext Micro and Connext Cert support applications running on devices with limited size, weight and power requirements, but these systems still assume a certain level of hardware and capability.

Yet, there is still room for more — or in this case, less!

RheinMain University ( in Wiesbaden, Germany, has spent years looking at using the OMG DDS standard in the sub-RTI Micro domain. Here is Kai Beckmann, Dipl.-Inform.(FH), M.Sc., discussing what they’ve been working on.

sDDS – An adaptable DDS Solution for Wireless Sensor Networks.

Wireless Sensor Networks (WSN, cf. ZigBee, 6LoWPAN) are maturing into real world applications, from classical environment monitoring, home automation and the internet of things to industrial automation scenarios. There are improvements regarding available hardware resources, but the energy consumption is yet a limiting factor, and so are the heterogeneous software and hardware platforms. The Data Distribution Service (DDS) provides a standardised interoperable data-centric publish/subscribe architecture with real-time capabilities, suitable for many data-centric WSN scenarios.

However, DDS is rooted in larger-scale architectures – the full middleware functionality generally exceeds the available resources on an average sensor node – and the RTPS network protocol is not tailored to the small network frames common to WSN. We therefore propose sDDS, a DDS implementation for minimal embedded systems found in WSN. A Model-driven software development (MDSD) process is utilised to specify the system structure and applications requirements of the DDS functionality, and to generate individual sDDS implementations for each node. Furthermore, we present SNPS as an alternative transport protocol for DDS communication, particularly in WSN scenarios. SNPS has been designed as part of sDDS, optimizing for minimal footprint and compatibility between sDDS instances with different subsets of functionality.

Longer term, I would like to work with RheinMain University, with the purpose of bridging their SNPS transport protocol into an RTPS-based, full RTI Connext DDS system — giving the full scale system direct, data-centric access to the WSN for the purposes of aggregation, C2 and HMI, and giving the WSN direct, data-centric access to full scale systems for off-node processing.

If the idea of data-centric Sensor Networks interest you, there’s still time to register to attend.

DDS, Security, Smart People, Great Leadership, Fun Lunches, and James Gosling = Magical Internship Reply

ramya_headshotby Ramya Pradhan

I was at an NBA Orlando Magic game when I received news confirming the summer internship offer from RTI.  I knew from the first time I learnt about the company through my doctoral research on fault tolerance in distributed systems that RTI would be an awesome place to gain hands-on experience in my field of research.  The internship far exceeded my expectations in giving me ample opportunities to learn, contribute, and grow both professionally and personally.  The people, the work culture, and the profound impact RTI has in the fast emerging field of Internet of Things make it among the coolest places to be.  Come along as I reminisce over my experiences as an Intern.

I am a Computer Science doctoral student at the University of Central Florida.  I work on bio-inspired models for fault tolerance in distributed systems.  It was during one of my literature review sprints that I became aware of RTI through Dr. Douglas C. Schmidt’s research on fault tolerance.  The more I became acquainted with the research at RTI on distributed systems and its vast reach in the industry, the more I wanted to be associated with RTI.  I was overwhelmed when I saw internship openings for summer and lost no time in applying!  The interview process was quite rigorous, but I thoroughly enjoyed talking to the engineers who were more than passionate about their work.  I knew right then that RTI was where I wanted to be – at a place where your passion for what you do is nurtured aplenty!

On accepting the offer, I was delighted to know that I would be working on RTI DDS Connext Secure.  Secure systems  has always been one of my favorites.  I eagerly looked forward to experience the confluence of security and distributed systems.  I vividly remember my first day at work like it was yesterday. I was excited.  I was nervous.  I was a little uncertain.  I did have the theoretical know-how, but had little practical hands-on experience with distributed systems in the industry.  After completing the initial orientation meetings with the HR, IT, Accounting, and Safety departments, I was introduced to the Engineering team and to my mentor, Yusheng, over lunch.  It was a fine gathering in the kitchen.  It reminded me of family dinners at the table.  Little did I know then that this would be among the things I would miss the most!  Next was the meeting I was most looking forward to – a meeting with the VP of Engineering, Jan.  He introduced me to the workings of the RTI DDS Connext technology, tools, and potential projects that I would work on.  I was given all the material that I needed to ramp myself up to begin work as RTI’s Software Engineering Intern for Security.

I spent the next two weeks learning.  I watched presentations by the CEO, read orientation handouts, installed software with guidance from the build notes and a lot of help from the fantastic support team, and had whiteboard discussions with Yusheng to facilitate my understanding of the team’s expectations.  It was a completely immersive experience for me; part of it fueled by my curiosity, but mostly by my colleagues’ enthusiasm for the work they did.  Never once did I find anyone too busy to help me with obstacles along the way.  Thinking back upon this very aspect reminds me of an ancient Indian adage – “Yatha raja, thatha praja” meaning, “As is the king, so are his subjects”.  I strongly felt the CEO’s Servant Leadership style infused in all my colleagues; it was others’ needs first.

Smart People, Great Leadership: With CEO Dr. Stan Schneider, CTO Dr. Gerardo Pardo-Castellote, and the engineers.

Smart People, Great Leadership: With CEO Dr. Stan Schneider, CTO Dr. Gerardo Pardo-Castellote, and the engineers.

Upon completing the initial training, I eagerly set forth to explore my tasks.  I started each day with a list of things to work on.  I would settle down with a freshly brewed cup of coffee from the kitchen and start working off my list.  By noon, the Engineering team would all go to get lunch from the neighboring fast food places or the food trucks.  We would bring the food to the kitchen and sit at the tables – family style!  From then on, it was an hour of pure fun!  It was like unwinding with friends in the middle of the day filled with laughter, funny anecdotes, super heroes, history and traditions – Belgian, Italian, Spanish, Mexican, Indian, and Chinese, and work humor.  Oh, what fun it was!  It was truly rejuvenating to get back to work after lunch.  Each evening, upon my request, Yusheng and I had a meeting to discuss my work and progress. This ensured that we knew each other’s expectations and would have little gap in communication.  My day ended with most things taken care of from my to-do list.  In leaving for the day, I would eagerly look forward to the next day; that was the magic of the work culture at RTI.

The internship gave me a valuable exposure to the challenges that exist in the field of developing messaging systems for distributed systems, particularly in secure messaging.  The internship reinforced my belief that challenges are just fantastic opportunities waiting to be uncovered.  I am grateful to my mentor for letting me explore some of those fantastic opportunities.  Some solutions were easier to come up with than others, but most of all I enjoyed the process of coming up with solutions.  It typically involved a lot of whiteboard discussions, extensive analyses of code dependencies, thorough planning for integrating new code, and comprehensive debugging.  The most important takeaway for me from this process was that work could make one happy.

Adventures: Meeting James Gosling, visiting Chabot Space Center and Redwood National Forest.

Adventures: Meeting James Gosling, visiting Chabot Space Center and Redwood National Forest.

As I look back on the things that I have learnt and gained over the past summer, I am filled with gratitude for being given the opportunity to do so. Top of the list are motivating leadership, working with intelligent, dedicated, and passionate colleagues, challenges that seek creative solutions, the feeling that exudes ‘All for one and one for all’ at weekly engineering team meetings, the super fun lunch hour, FIFA world cup matches, and definitely, meeting James Gosling!  Thanks so much, Jan, for letting us know that James Gosling was in a restaurant near by!  Well, the Orlando Magic lost the game that day, but I won the most magical summer.  Thank you RTI for showing not only can one’s distributed system achieve impossible tasks when working as one but so can a company working as one – #1RTI.

ramya internship rti sunnyvale engineering

DDS Security: Completion of my first project under the able guidance of my mentor Yusheng Yang.

Leveraging W3C Org Documents (XML, etc) in RTI Connext DDS Reply

london connext conference rti EMEA 2014

Connext Conference 2014 is taking place 8-9 October in London. To learn more or RSVP, visit

This is an abstract of a demo that RTI plans to have available at the RTI Connext Users Group meeting, to be held in London next month (

Working with structured data, each domain (Enterprise, Real-Time, Java ESB, etc.) will have its preferred method or defined structure for in-memory, and for stored data instances. The fun is when you move across the boundaries from one domain to another, or when you want to leverage one standard’s structures within a non-native domain.

The W3C consortium defines a Document Object Model to hold data in-memory, as well as XML and the Schema-for-Schemas, XSD, used when you want to serialize the data and communicate it to a third party. In OMG DDS, the equivalents are the Dynamic Data Object and Type-specific object PSMs, and RTPS serialization when transmitting instances.

Various ways to leverage the W3C standards in an RTI Connext DDS environment are demonstrated, including:

  • DCPS Discovery information to XML, useful for:
    • Self-documenting DDS Domains
    • Capturing snapshots of what is on a DDS Domain
  • Discovered Type information to XSD or XML, useful for:
    • Auto-generated Type info, formatted as XML for use with RTI Tools that can read XML-defined Types
    • Auto-generated XML Schema Documents, for XML files that can be used to pre-load instances with specific information (‘Configuration Propagation’, ‘Test’, and other use-cases)
  • Generating XSD information for use by Enterprise tools (that can’t read IDL)
  • etc

An example Java application is demonstrated, that uses DCPS Discovery Topics to generate XML and XSD files, as well as show how to read in XML files for use by DDS applications, either for remote configuration (when published as Last-Value-Cache for example), or for pre-loading Type instances for publication via:

ShapeTypeExtended steInstance =
"MyXmlInstances.xml", "YellowTriangleThree");

Service Provision and Discovery Reply

london connext conference rti EMEA 2014

Connext Conference 2014 is taking place 8-9 October in London. To learn more or RSVP, visit

This is an abstract of a demo that RTI plans to have available at the RTI Connext Users Group meeting, to be held in London next month (

The Oasis Reference Architecture for Service Oriented Architecture defines the concepts surrounding service ‘reachability’, including the use of Federated Service Registries (what services are known about) and Service Repositories (what you need to know, to access a service).  Once your Consumer knows what Services are available, and also how to attach to a given Service Interface, you’re now rocking that SOA.  So how does that apply to a real-time SOA, using DDS?

If you sort of squint at it, the DDS anonymous DCPS Discovery protocol is a part of the Service Registry.  For the Service Repository, Discovery also can supply you with the Types, but only supports the pub-sub integration pattern.  There isn’t any automated, or standards-driven, protocol for doing this using DDS.

To get a full, Federated Registry-Repository (cf Figure 38, page 63 of the reference document linked above), you can implement a Service Discovery process.  Using a well-known topic and type, you can search for suitable Service Interfaces (based on Search or Keywords, etc), determine what integration pattern a Service uses, find the Topics that are needed for it, and merge that information with the normal DCPS Discovery discovered information.  The end result is to build, ad-hoc, the necessary infrastructure to accesses that Service’s Interface — without requiring a maintained Repository.

For the London Connext Conference, RTI has a Raspberry Pi with an attached Pressure/Altimeter/Temperature sensor that publishes using pub/sub.  A service starts up and subscribes to the PAT data, which it then offers (as a Service Interface) via Request/Reply and “Last Value Cache” QoS.  The Service publishes a provision instance, loaded from an XML file, on a well known topic (“Service Provision”).  The instance includes particulars of the Service Interface:  This service uses Simple Request Reply, This is the Request Topic, the Reply Topic, with respective topic Type names, these are my human defined keywords.

A service consumer can now query the “Service Provision” topic using a content filter on the keywords, to find an arbitrary Temperature Service, identify that it is Simple Request/Reply, create the necessary Request writers and Reply readers (using the Types from normal Discovery process), make a request and process the reply.  The only foreknowledge the Consumer has, is that there may be a Temperature sensor on the network that uses a specific set of keywords.

Mark Your Calendars! Reply

rti connext dds road show safety security distributed systems

Build Safe & Secure Distributed Systems for Aerospace & Defense: How to Meet DoD Open Architecture Requirements and Cyber Security Guidance

Build Safe & Secure Distributed Systems for the Industrial Internet of Things: How to Architect Scalable Systems for the Industrial Internet using Open Standards

 To stay up to date on the latest RTI news and events, be sure to follow us on twitter and visit our events page.

Connext Conference London! Reply

connext conference london rti dds users group

Connext Conference London is going to be held on October 8th and 9th and we’d love to see you there!

This 2 day event kicks off with a Connext DDS Users Group meeting where we’re going to focus on the topics that matter the most to you. We’re kicking off the event with a Keynote from Bryn Balcombe, Technology Director at London Live. He is going to speak discuss how the Industrial Internet technologies and protocols will change the way we experience live events – in the venue, in the home and on your phone

Throughout the event you’ll have ample opportunity to network with other DDS developers, share your experiences, and gather insights.

For registration, schedule details, up-to-date information on speakers, and all general information relating to Connext Conference London, visit or reach out to our EMEA sales team at

connext conference london rti dds users group

Let Your LabVIEW VI Go Mobile. Reply

Picture1My smartphone has become an essential part of my life. Not only do I have my phone with me wherever I go, but it provides me with capabilities that touch all sorts of aspects of my day to day life. My current favorites:

  1. Provides me with instant access to my emails, and people with instant access to, well, me. (bit of a double-edged sword)
  2. Contains the information about all my different membership cards.
  3. Allows me to control my home (e.g. alarm system, lights, garage door), remotely.

But it doesn’t end there! I read books on my phone, check traffic, get directions, and take pictures. My phone even has become my boarding pass when I’m on travel. It makes me sometimes wonder if there’s anything my phone can’t do. There is.

I can’t just run any application that I am used to from my laptop or PC on my phone. Depending on what I used to create my application, I might not be able port it to my phone. Applications have to be re-written in a language. LabVIEW is a great tool for for creating custom applications that interact with real-world data or signals in fields such as science and engineering. The graphic programming approach makes it easy to manipulate data and provide visualization of information. However I can’t run any LabVIEW programs on a phone or tablet. 

National Instrument’s LabVIEW programs are called virtual instruments, or VIs, because their appearance and operation imitate physical instruments, such as oscilloscopes and multimeters. LabVIEW contains a comprehensive set of tools for acquiring, analyzing, displaying, and storing data, as well as tools to help you troubleshoot code you write. In LabVIEW, you build a user interface, or front panel, with controls and indicators. Controls are knobs, push buttons, dials, and other input mechanisms. Indicators are graphs, LEDs, and other output displays. After you build the user interface, you add code using VIs and structures to control the front panel objects.

It just so happens that LabVIEW supports a variety of platforms (e.g. Linux, Windows) but unfortunately you can’t run a LabVIEW VI directly on a mobile (android or iOS) device. That’s unfortunate since my phone is almost always on me. Thankfully, National Instruments does provide a Data Dashboard for LabVIEW which is great to create a custom dashboard on mobile devices.

The Data Dashboard is as its name suggests: a dashboard to display information. The Data Dashboard communicates by networking deployed NI Shared Variables, LabVIEW Web Services with visual objects like graphs, meters, and switches among many other available controls and indicators.  If you’re developing a mobile application, this can offer you some great elements, but you need something more. What’s the value? What problem can it solve? A mobile application should to be more a Data Dashboard some buttons. What data is it operating on?

Applications on mobile devices can do more than just being a dashboard or front end for information. Sometimes you can add additional value to mobile application by making use of features provided on the devices. Location services is a common native feature that app developers leverage.  So how can I build an application that can leverage my mobile phone’s capabilities and run  on the mobile platform? Simple. I use the RTI DDS Toolkit for LabVIEW alongside RTI Connext DDS for mobile devices.

The RTI DDS Toolkit for LabVIEW and RTI Connext for mobile devices here is the perfect solution which allows for custom application which can take advantages of running on a mobile platform. 

Often it is not just mobile applications. In some cases you have legacy application or applications outside of LabVIEW which need to share information with the LabVIEW program. The same mechanism which can be used for mobile applications can also be used to interface with non LabVIEW applications. The RTI Connext solution also allows for easy interfaces with LabVIEW VIs from any non-LabVIEW application thanks to the use of DDS. The specification for DDS provides great capability for applications that want to leverage the distribution of state data. Not only can you specify the type of data of your interface but you can also specify the behavior of how that data will be delivered. For example you application can get the latest state information automatically when it starts up. No need to run queries. You can define how much historical data you want. This eliminates a lot of the programming otherwise needed to get the application in the right state at start-up.

labview-ecosystem connext DDS toolkit

Another advantage of using the RTI DDS Toolkit for LabVIEW is that the publish/subscribe pattern allows for multiple mobile applications to interface with the LabVIEW VI without having to change the VI or the VI’s configuration. This allows you to build completely open systems which can easily be extended with new applications without having to modify existing programs.

In some cases, it is not desired to have a degree of openness that allows for any application to publish or subscribe to data. With the new secure DDS standard which supports fundamental security techniques and fine granularity of control allows you to control what can be let out of the cyber world and what has to stay securely locked in. Secure DDS let you control who has the rights to see, publish, and subscribe to data on a per topic basis. This allows for building systems that are easily extendable but provide secure access to data. This is especially important when communicating through a public network.  Connext DDS Secure provides the world’s first standards-compliant, off-the-shelf messaging platform that delivers the security, performance and safety required for deployment of the Industrial Internet of Things. It complies with the new Data Distribution Service (DDS) Security specification from the Object Management Group (OMG).

Let’s look at an example how information can be shared between mobile applications and LabVIEW VIs. The first step is defining the interface between the mobile application and your LabVIEW VI. At the minimum there is status information from the VI to the mobile application and command like information from the application to the VI. In RTI Connext the data type would be specified in IDL, in LabVIEW as a cluster. Let’s assume we want to track some assets. The status information would contain it’s position (longitude and latitude), speed, and direction as compass heading (0-360 degrees). The type could be defined in IDL as follow:

struct status {
    float longitude;
    float latitude;
    float speed;
    long direction;

In LabVIEW the corresponding cluster looks like this:

labview vi cluster rti connext dds

Now that the interface is defined we need to create an application which subscribes to the status and the VI which publishes the status updates. The RTI DDS Toolkit for LabVIEW Getting Started Guide explains how to create a DDS writer for complex type. The example uses the created cluster as control for the input values. However in most applications the actual values will come from external sensors. So we have to create the cluster using the Bundle Function. The bundle function uses the cluster definition as reference and has inputs for the different cluster elements. Here is an example of creating the cluster:

labview vi cluster rti connext dds

The cluster is then passed to the RTI Connext Complex Data writer.

On the mobile platform the application can be developed like any other application using RTI Connext. The above example is for the status message from the LabVIEW VI to a mobile application. Additional messages can be used for information flowing in either direction. For messages from the mobile application the VI would be the subscriber and the mobile application would be the publisher.  The information would be received as a cluster in the VI and can be broken up in separate variables using the unbundle function similar to how the bundle function was used in the example above.

Once the data types are defined and the next step is to define the behavior of how data is delivered by fine tuning the DDS QoS settings as described in the following blog .

Don’t feel limited to the platforms LabVIEW supports when creating your system. The RTI DDS Toolkit for LabVIEW and RTI Connext DDS make it possible to take your system anywhere. The use of DDS allows you to develop global systems regardless of operating system, location, and programing languages. RTI Connext truly enabled your systems to work as one.

Replacing ZeroMQ with RTI Connext DDS in an Actor Based System 7

Scalability is one of the key properties of modern software that allows for applications to adapt to changes in the context where they’re operating. Nowadays, distributed architectures, cloud computing, and multicore processors change the development of concurrent programming such that they help to fulfill scalability requirements. In these scenarios, the traditional shared state programming has shown its limit: threads must be able to synchronize to guarantee concurrency. This can be a complex, tricky, and expensive operation that if it is not done correctly, can easily lead to race conditions, deadlocks, or starvation; possibly compromising the overall performance of the system.

A different approach to concurrency can be used to address those problems – the Actor Model. The actor model provides a lightweight and isolated isolated way to create entities that don’t share state and that communicate only through asynchronous non-blocking messages, both locally and in distributed systems. Since they don’t share state, they can easily be used to achieve high concurrency and scalability in systems with distributed architectures and multicore processors.

As shown in Figure 1, in an actor based system, the actor can be seen as the fundamental unit of computation that embodies:

  1. Behavior: what does the actor do
  2. State: a set of variables that can be changed by the behavior
  3. Communication: how does the actor communicate with other actors

Figure 1: an actor is defined by a state, a behavior and a mailbox

Each actor in the system has a ‘mailbox’ and it becomes active only when another actor sends a message to their mailbox. Upon receipt of a message, the actor can:

  1. Create new actors
  2. Send messages
  3. Produce side-effects (e.g. write a file)

One of the most popular solutions based on the Actor Model is Akka: a toolkit and runtime framework for building highly concurrent, distributed, and fault tolerant applications on the JVM. Akka is written in Scala and has language bindings for Scala and Java. It has a modular structure that can easily be extended with the so-called ‘Extensions’.

In Akka, actors are purely reactive components: an actor is passive until a message is sent to it. When a message arrives to the actor’s mailbox one thread is allocated to the actor, the message is extracted from the mailbox and the actor applies the behavior. When the processing is done, the thread is returned to the pool. This way actors don’t occupy any CPU resources when they are inactive.

The actor’s behavior is the computation logic that is executed in response to a message. The internal state of the actor can change only as a response to a message, and the only way to observe the state is via message exchange. An actor can only process one message at a time—there is no need of synchronization nor coordination.

To define an actor in Akka, you have to extend the Actor trait, implementing the receive method, which is never called concurrently.

class MyActor extends Actor {
    def receive = {
        case “test” ⇒ println(“Receive test message”)
        case “send” ⇒ sender ! message
        case _      ⇒“Unknown message”)

The receive method returns a PartialFunction, e.g. a ‘match/case’ clause in which the message can be matched against the different case clauses, using Scala pattern matching.

To create an actor, first an ActorSystem has to be created. Calling the actorOf method will return a reference to the actor. To specify options, it is possible to pass a configuration class to the actorOf method.

val system = ActorSystem("mySystem")
val myActor = system.actorOf(Props[MyActor], "myactor")
val child = context.actorOf(Props[MyActor], name = "myChild")

To send a message to an actor, you have to use the ! (bang) function, which is asynchronous and non blocking. The semantic of delivery is at-most-once both for local and remote actors. Thanks to the message passing communication of actor model, there is no tight-coupling between sender and receiver. Actors are location transparent and distributable by design; actors share no data and communicate using message passing, they can be mapped on a distributed architecture (scaling out).

Remote communication can be achieved using:

  1. Configuration files: the same system can be configured as distributed without code changes.
  2. Extensions

If the actor is a remote actor, it uses remote call under the hood. Akka can be configured to use various transports. The default transport mechanism is a Netty based TCP driver. Netty is an asynchronous event-driven framework for the development of maintainable and high performance applications. Asynchronous one-to-one channels are created between remote actors. So, sending a message to remote actors serializes the message transparently and sends it to the remote JVM. However, this solution is particularly inefficient for one-to-many communication patterns, as each message is replicated on the physical channel for each receiver.

Below, there is the snippet of a configuration file that uses the default Netty transport for remote communications. It specifies hostname and port parameters (passed to the remote system) to identify the system:

actor {
    provider = "akka.remote.RemoteActorRefProvider"
remote {
    enabled-transports = ["akka.remote.netty.tcp"]
    netty.tcp {
        hostname = ""
        port = 2552

Akka has two ways of using remote communication: lookup a remote actor and create a remote actor.

To lookup an actor on a remote node, you can use the actorSelection(path) method:

val selection = 
        "akka.tcp://actorSystemName@ /user/actorName")
selection ! "Hello"

To create an actor on a remote node, you can use actorOf(Props[...], actorName) method instead, specifying in the configuration file of the application where the remote actor resides, using the address and the port of the remote system:

actor {
    deployment {
        /myActor {

The same semantics are used for sending messages to remote and local actors—there is no API dedicated for remote communication. If no deployment configuration exists, then actor is deployed locally.

Using Netty, a remote actor that wants to communicate to multiple actors has to know each receiver and replicate the message for each Netty TCP channel. This is clearly inefficient and difficult in scenarios where actors are mobile (i.e., they enter and exit the system frequently). For this reason a PUB/SUB communication pattern is needed.

Akka’s modular structure makes it easy to add external features and to manage them thought Akka itself.

Akka supports the PUB/SUB communication pattern through the ZeroMQ Extension. ZeroMQ is an asynchronous messaging library with a non-dedicated message broker. It supports different transports such as IPC, multicast (PGM), and TCP communication. The main disadvantage in using ZeroMQ as the base for PUB/SUB in Akka is its limited QoS capabilities. Also, the ZeroMQ PUB/SUB sockets are using TCP or PGM and there is no guarantee of reliability as slow subscribers drop messages. Other kinds of ZeroMQ sockets and other patterns can be used (e.g. ROUTER-DEALER), with the downside of increasing the complexity of the application.

To overcome these problems we decided to replace ZeroMQ with DDS. To do this, we developed an Akka Extension using RTI Connext DDS. Our Connext DDS extension follows Akka’s modularity principles, and thus can be easily integrated in an Actor System and used to integrate actors to a pre-existing systems based on DDS. The DDS Extension allows efficient one­-to-­many communication through the PUB/SUB Model offered by DDS.

The RTI Connext DDS extension adds a wide range of QoS policies to have the best delivery semantics for application-­level requirements, trade­-off between quality guarantees, and communication costs. For these reasons, we feel that the DDS extension represents an improvement in comparison with the ZeroMQ Extension.

Using DDS, actors can now exchange messages with one another, so long as they’re registered to the same DDS topic. This is accomplished using a proxy actor, called ActorDW, which encapsulates a DDS DataWriter. Other actors in the system send messages to ActorDW, using the usual actor syntax. A representation of the complete interaction is represented in Figure 2.


Figure 2: Interaction between ActorDW and DDS

The operation of loading the extension is similar to the ZeroMQ extension, as well as the rest of the extensions available for Akka:

val system = ActorSystem("DDSAkkaSystem")
val dds = DDSExtension(system)

The DDSExtension API is higher-level and more abstract than ZeroMQ extension’s. To publish a message the extension offers the newDataWriter method. The user has to specify only DDS’s DomainID, the topic name, and the name of the actor:

val actorDW = dds.newDataWriter(0, "My Topic", "myActorDW")

The method will return an actor that can be used with the usual bang syntax:

actorDW ! message

Using newDataWriter method in its simplest form, will use default values for DataWriterQoS,
DomainParticipantQos, and TopicQos. However a user can specify its own custom QoS parameters:

val qosDataWriter = DataWriterQos()
qosDataWriter.reliability(Reliability = Reliable)
val qosTopic = TopicQos()
qosTopic .reliability(Reliability = Reliable)
val actorDW = dds.newDataWriter(qosDataWriter , qosDomain, qosTopic, 0, "Test Topic", "datawriter")

In Figure 3 we see the actions hidden from the user; these actions are executed automatically by the DDSExtension  and include:

  1. Retrieve or create the DDS Domain
  2. Retrieve or create the Topic
  3. Create a DDS DataWriter
  4. Create and return the actor

Figure 3: actions performed under the hood for a DataWriter Actor

On the subscriber’s side, the extension provides the newDataReaderWS method. Firstly, the user has to create the actor that will receive the data, and then pass it to the method:

val actorDR = system.actorOf(Props[DRActor], "MyActorDR")
dds.newDataReaderWS(0, "Test Topic", actorDR, read)

Even in this case, the method has two forms: the simplest one gives default values for DataWriterQoS, DomainParticipantQos, and TopicQos, but users can specify their own custom QoS settings:

val qosDataReader = DataReaderQos()
qosDataReader.reliability(Reliability = Reliable)
val qosTopic = TopicQos()
qosTopic.reliability(Reliability = Reliable)

val actorDR = dds.newDataReader(qosDataReader , qosDomain, qosTopic, 0, "Test Topic", read)

The actions that the API performs are illustrated in Figure.


Figure 4: action performed automatically by the ActorDR

The system, creates a DDS DataReader and then registers the actor and the DataReader in a data structure, which depends on the type of the condition, contained in another component called DDSDemultiplexer.
The DDSDemultiplexer, illustrated in Figure 5, is a singleton that wraps a DDS WaitSet and offers methods to attach and detach conditions.


Figure 5: DDSDemultiplexer structure

At system startup, a thread is assigned to the DDSDemultiplexer, and it will block itself waiting for samples0. As shown in Figure 6, when a DataWriter writes some data into the Topic, the thread will be awake, and it will check if there are actors registered for that particular event. If so they will be notified.


Figure 6: DDSDemultiplexer loop waiting for data and then it notifies the DataReader when new Data is available

val readConditions = Map[ReadCondition, DDSNode]()
val statusConditions = Map[StatusCondition, DDSNode]()

while (running) {
    val retcode = ws.wait(activeConditions, timeout)
    val cond = activeConditions.get(i)
    val node = statusConditions.get(cond)

    getSample(cond, node)

As you can see, the Actor Model is an interesting approach you can use to solve issues related to concurrency, especially in distributed systems. We explored the challenges and the limitations when it comes to remote actors in regards to one-to-many communication patterns, showing how PUB/SUB is necessary to implement scalable solutions. We also illustrated the limitations of the ZeroMQ Extension for PUB/SUB, most notable concerning QoS configurations. For these reasons, we implemented an easy to use RTI Connext DDS extension that, with minimal effort from the user, can be easily tuned and configured. Using this approach, actors can now communicate, using RTI Connext DDS, where they’re able to take advantage of the PUB/SUB model and the great QoS support out of the box.

If you have any questions, feel free to comment and we will get back to you ASAP!

Note: This Blog post was written by Marco Franzoni (University of Bologna) and Gianpiero Napoli (RTI) and is part of Marco’s recent work for his M.Sc. Degree in Computer Engineering from the University of Bologna: “Quality-of-Service Support in Distributed and Wide-Scale Actor Systems”

Simplifying the use of DDS 1

The specification for DDS provides great capability for applications that want to leverage the distribution of state data in a very customized efficient manner. I say customized here because not only can you specify the unique type of data but you can also specify the behavior of how that data will be delivered, persisted, filtered and stored within the middleware. Actually, the capabilities provided by DDS are not unique to data communications between systems. However, what DDS provides is all of this functionality within the middleware, thus eliminating the need for your applications to provide the same. No coding necessary to filter data based on satisfying a range specification on one or more of the fields within your data. No coding necessary to provide previously published data to late joining applications. No coding necessary to enable the storage of a historical data publications for live trending analytics to be performed. No coding for these things means application developers can spend their time on more important unique aspects of their application and thus a deliver a better end product with shorter time to market. All of this functionality is enabled and specified through simple code generation and configuration elements known as Quality of Service. As you might guess, this configuration can become difficult to create and manage. If someone is just getting started with understanding DDS, this can become a daunting task to undertake. In order to address this initial view of DDS for developers, there are few things that we have done here at RTI to help with simplifying the use of DDS for some basic applications. Take for example, the process of creating a unique data type, running code generation, setting up a project and including all of the generated files in to the project. For a very simple type, this process seems a little excessive. We have eliminated the need to perform this process for a few simple types. In fact, our latest version of DDS, RTI Connext DDS, includes built-in types for 2 basic types:

  • String    // Simple ASCII String message
  • Octet     // Simple byte array message

We also provide keyed versions of these if you want have unique instances of these. The use of these built-in types can be found within our User Manual for DDS and can save a lot of time when creating your applications. Next, we have taken the complexity of having to learn and create Quality of Service profiles for each specific type of data flow in your system and have reduced them down into a set of built-in behavior profiles that can be used directly within your application. These built-in profiles will eliminate the need to of spending hours and hours pouring over our great documentation on each of the various Quality of Service behaviors. Literally this can shorten your time to getting started in creating a DDS publish / subscribe application from several days into an effort that is less than a couple of hours. The great thing about these behavior profiles is that they represent about 75% of the most common use cases we have found projects using out in the field. Here are a few of the built-in profiles:

  • Best Effort
  • Reliable Keep Last One
  • Pattern Streaming
  • Pattern Event
  • Pattern Status



We have provided some great examples of built-in profiles available for you to download and use up on our Community Portal. You can find the examples here:

In addition to these examples, here are some other things up on Community that may be of interest:

Let us know what you think about these aspects of Simplifying the Use of DDS!