+
.. This work is licensed under a Creative Commons Attribution 4.0 International License.
.. SPDX-License-Identifier: CC-BY-4.0
.. CAUTION: this document is generated from source in doc/src/rtd.
.. Do NOT make changes directly to .rst or .md files.
+
RMR Developer Guide
============================================================================================
-The RIC Message Router (RMR) is a library which applications
-use to send and receive messages where the message routing,
-endpoint selection, is based on the message type rather than
-on traditional DNS names or IP addresses. This document
-contains information that potential developers might need to
-know in order to contribute to the project
+The RIC Message Router (RMR) is a library for peer-to-peer
+communication. Applications use the library to send and
+receive messages where the message routing and endpoint
+selection is based on the message type rather than DNS host
+name-IP port combinations.
+
+This document contains information that developers need to
+know to contribute to the RMR project.
Language
--------------------------------------------------------------------------------------------
RMR is written in C, and thus a contributing developer to the
core library should have an excellent working knowledge of C.
-There currently is one set of cross languages bindings
+There currently is one set of cross-languages bindings
supporting Python, and a developer wishing to contribute to
the bindings source should be familiar with Python (version
3.7+) and with the Python *ctypes* library.
RMR is designed to provide an insulation layer between user
applications and the actual transport mechanism. Initially
-RMR was built on top of Nanosmg, and shortly after was ported
-to NNG (Nanomsg Next Generation). Because RMR presents the
-same API to the user application regardless of the underlying
-transport library, the resulting output when compiling RMR is
-a transport specific library. As an example, librmr_nng.a is
-the library generated for use with the NNG transport.
+RMR was built on top of the third-party library Nanosmg,
+shortly after was ported to the third-party library NNG
+(Nanomsg Next Generation), and then was ported to an
+internally developed socket library called SI95. RMR presents
+the same API to the user application regardless of the
+underlying transport library, but the resulting output when
+compiling RMR is always a transport-specific library. As an
+example, librmr_nng.a is the library generated for use with
+the NNG transport.
As such the library source is organised into multiple
components:
common
Source in the common directory is agnostic to the
- underlying transport mechanism (Nanomsg or NNG), and thus
- can be used when generating either library.
+ underlying transport mechanism (Nanomsg, NNG, SI95, ..),
+ and thus can be used when generating either library.
nano
nng
Source which is tightly coupled with the underlying NNG
+ library. (NNG has been deprecated, but the RMR source
+ remains as an example.)
+
+si
+
+ Source which is tightly coupled with the underlying SI95
library.
Internal Function Exposure
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The decision to limit as much as practical the exposure of
-truely internal RMR functions was made, and as a result most
+truly internal RMR functions was made, and as a result most
of the RMR functions carry a static label. In order to
modularise the code as much as possible, this means that the
-primary module (e.g. rmr_nng.c) will directly include other
-RMR modules, rather than depending on referencing the
-internal functions during linking. While this is an
-infrequently used approach, it does mean that there are very
-few functions visible for the user application to reference,
-all of them having the prefix rmr\_, while allowing internal
-functions to have shorter names while still being meaningful.
+primary module (e.g. rmr_nng.c) directly includes other RMR
+modules, rather than depending on referencing the internal
+functions during linking. While this is an infrequently used
+approach, it does mean that there are very few functions
+visible for the user application to reference, all of them
+having the prefix rmr\_. This allows internal functions to
+have shorter names while still being meaningful.
Coding Style
--------------------------------------------------------------------------------------------
existing module, respect the author's choice where style
alternatives are not frowned upon. When creating new modules,
select a style that fits the guidelines and is easy for you
-to work with. There are a few things that are insisted on by
-the maintainers of RMR, but for the most part style is up to
-the creator of a module.
+to work with. There are a few things that the RMR maintainers
+insist on, but for the most part style is up to the creator
+of a module.
Building
--------------------------------------------------------------------------------------------
RMR is constructed using CMake. While CMake's project
description can be more cumbersome than most typical
Makefiles, the tool provides convenience especially when it
-comes to creating packages.
+comes to creating DEB/RPM packages.
Code Review / ric-plt / lib / rmr.git / blobdiff