Skip to content
Search

Nanomsg-next-gen

lastmod 2025-02-14created 2019-03-2020 edits

nanomsg-next-generation - light-weight brokerless messaging. 

This project is a rewrite of the Scalability Protocols library known as libnanomsg, and adds significant new capabilities, while retaining compatibility with the original.

About

NNG, like its predecessors nanomsg (and to some extent ZeroMQ), is a lightweight, broker-less library, offering a simple API to solve common recurring messaging problems, such as publish/subscribe, RPC-style request/reply, or service discovery. The API frees the programmer from worrying about details like connection management, retries, and other common considerations, so that they can focus on the application instead of the plumbing.

NNG is implemented in C, requiring only C99 and CMake to build. It can be built as a shared or a static library, and is readily embeddable. It is also designed to be easy to port to new platforms if your platform is not already supported.

The communication patterns, also called "scalability protocols", are basic blocks for building distributed systems. By combining them you can create a vast array of distributed applications. The following scalability protocols are currently available:

  • PAIR - simple one-to-one communication
  • BUS - simple many-to-many communication
  • REQREP - allows to build clusters of stateless services to process user requests
  • PUBSUB - distributes messages to large sets of interested subscribers
  • PIPELINE - aggregates messages from multiple sources and load balances them among many destinations
  • SURVEY - allows to query state of multiple applications in a single go

Scalability protocols are layered on top of the transport layer in the network stack. At the moment, the nanomsg library supports the following transports mechanisms:

  • INPROC - transport within a process (between threads, modules etc.)
  • IPC - transport between processes on a single machine
  • TCP - network transport via TCP
  • WS - websockets over TCP

The library exposes a BSD-socket-like C API to the applications.

It is licensed under the MIT/X11 license.

Messaging Patterns

nng is a messaging framework that attempts to help solve common messaging problems with one of a few patterns ('protocols' in nng parlance.)

Pipeline (A One-Way Pipe)

Pipeline This pattern is useful for solving producer/consumer problems, including load-balancing. Messages flow from the push side to the pull side. If multiple peers are connected, the pattern attempts to distribute fairly.

  • This pattern is useful for solving producer/consumer problems, including load balancing.
  • Messages flow from the push side to the pull side.
  • When multiple peers are connected, the pattern tries to distribute fairly.

Request/Reply (I ask, you answer)

Request/Reply Request/Reply is used for synchronous communications where each question is responded with a single answer, for example remote procedure calls (RPCs). Like Pipeline, it also can perform load-balancing. This is the only reliable messaging pattern in the suite, as it automatically will retry if a request is not matched with a response.

  • Request/reply is used for synchronous communication in which each question is answered with a single response, such as remote procedure calls (RPC).
  • Like Pipeline, it can also perform load balancing.
  • It automatically retries when a request is not matched with a response, so it is the only reliable messaging pattern in the suite.

Pair (Two Way Radio)

Pair The pair pattern is used when there a one-to-one peer relationship. Only one peer may be connected to another peer at a time, but both may speak freely.

  • The pair pattern is used when there is a one-to-one peer relationship.
  • Only one peer can be connected to another peer at a time, but both can speak freely.

Pub/Sub (Topics & Broadcast)

Pub/Sub This pattern is used to allow a single broadcaster to publish messages to many subscribers, which may choose to limit which messages they receive.

  • This pattern is used to let a single broadcaster publish messages to multiple subscribers.
  • They can choose to limit the messages they receive.

Survey (Everybody Votes)

Survey The surveyor pattern is used to send a timed survey out, responses are individually returned until the survey has expired. This pattern is useful for service discovery and voting algorithms.

  • The survey pattern is used to send out a time-limited survey, and responses are returned individually until the survey expires.
  • This pattern is useful for service discovery and voting algorithms.

Bus (Routing)

Bus The bus protocol is useful for routing applications, or for building fully interconnected mesh networks. In this pattern, messages are sent to every directly connected peer.

  • The bus protocol is useful for routing applications or for building fully interconnected mesh networks.
  • In this pattern, messages are sent to every directly connected peer.

TCP implementation

Check the tcp_conn_dowrite() and tcp_conn_doread() functions in src/platform/posix/posix_tcpconn.c. The APIs used are sendmsg and readv.

Troubleshooting

localhost connection problem when using the TCP protocol

When trying to connect over the TCP protocol, the connection may not succeed.

For reference, check the /etc/hosts file for localhost. 

127.0.0.1       localhost
255.255.255.255 broadcasthost
::1             localhost

It may be an IPv4 or IPv6 connection problem.

Binding with tcp://0.0.0.0:20002 results in the following. (You can check it with isof) 

c2node     9683 yourname   16u  IPv4 0x9ffbc70c9776a8f5      0t0  TCP *:20002 (LISTEN)

Using tcp://*:20002 results in the following. 

c2node     9683 yourname   16u  IPv6 0x9ffbc70c9776a8f5      0t0  TCP *:20002 (LISTEN)

Therefore, it is a good idea to check the IP version when the client connects.

See also

Favorite site

References

  1. Dissecting_Message_Queues_–_Brave_New_Geek.pdf ↩

  2. Priotitised_Load_Balancing_with_nanomsg_-_250bpm.pdf ↩

author Zer0 sitemap