Protocols in an RTist model are often binary, meaning that there are two connected ports typed by the protocol. The out-events for one of the ports are the in-events for the other port.

This is expressed by making one of the ports conjugated (denoted by ~). Hence, for a conjugated port the direction of protocol events is swapped so that the out-events can be sent in and the in-events sent out from it.

Conjugated Ports


A binary protocol MyProtocol typing two connected ports p1 and p2. The event that can be sent out from p1 (OutEvent1) can be sent in to p2, and the event that can be sent in to p1 (InEvent1) can be sent out from p2. The port p2 is therefore conjugated to swap the event directions specified in the protocol.

In the above example, it doesn’t matter which of the ports that are conjugated. However, when you are modeling a client-server design, a useful recommendation is to conjugate the server ports rather than the client ports.

Even if the opposite also works, you get two benefits by following this recommendation:

  1. All events that are sent from the client to the server are out-events, and all events that are sent from the server to the client are in-events. This makes send- and invoke-statements in the client capsule easy to read. Communication in client-server designs is usually initiated by clients rather than the server.
  2. There are typically more client ports than server ports, so by choosing to conjugate the server ports you save some clicking in the Properties view.


Client Server Design


A client-server design with 1 server port and 2 client ports. The client ports are named according to the server to make send- and invoke-statements in the client capsules easy to read.

If you want to change which ports that are conjugated, you also need to swap the directions of all events in the protocol of those ports. RTist provides a handy command for doing this. Select all events in the protocol, right-click and choose the command Change Event Direction. All in-events will become out-events and vice versa.

Comment wrap
Further Reading
Developing Stateful, Event-driven and Real-time Applications
Secure DevOps | September 2, 2020
Developing Stateful, Event-driven and Real-time Applications
HCL RTist is an Eclipse-based modeling and development environment for creating complex, event-driven, real-time applications in C++.
Now Available: RTist 11.0 2020.33
Secure DevOps | August 26, 2020
Now Available: HCL RTist 2020.33
HCL RTist 11 2020.33 is now available with several improvements in various areas.
Introducing Design Room ONE Version 2.1
Secure DevOps | July 23, 2020
Introducing Design Room ONE Version 2.1
The latest Sprint 2020.26 bring us a new version 2.1 of Design Room ONE available for HCL RTist users. In this new version authentication functionality has been significantly improved and lost its EXPERIMENTAL tag. One of the improvements includes refactoring the way the Design Room ONE server integrates with Keycloak for authentication. As a result, the configuration procedure is now easier: all the settings that need to be updated are now located in Design Room ONE’s main configuration file – server-config.json. Due to these improvements, there is now no need for Design Room ONE to store a Keycloak administrator key making this integration even safer, since Design Room ONE server would only be able to access pieces of Keycloak information it needs to manage access to its designs. You can refer to Authentication Setup for detailed instruction on migrating Keycloak realms configured with previous versions of Design Room ONE without loosing any information about users and their roles. Another update related to server configuration is the introduction of a single property dr_db_url controlling database connection — provides more flexibility and allows using password protected databases, which are standard in cloud environments like Azure or AWS. This is since version 2.1 Design Room ONE supports integration with Collaborative Lifecycle Management (CLM) tools version If you are using CLM tools to track your requirements with CLM (read System Requirements for the full list of supported versions and other requirements) you would be able to create “Derived From” links in your modeling tool e.g. HCL RTist from a model element to a requirement. These links will be visible in Design Room ONE after the model has been exported to the server. After that matching “Derives Architecture Element” links will be visible in your requirements management application and you would be able...
a/icon/common/search Created with Sketch.