Middleware Protocol

While Bristlemouth provides a networking layer that is generally protocol agnostic at the application layer (barring some constraints around things like lack of TCP, fragmentation support, out-of-the-box unicast routing, etc), it does provide users a readily available Middleware solution that is tailored to take advantage of the underlying discovery and routing features provided by the Bristlemouth Network Stack.

This default middleware implementation is tentatively named Bristlemouth Simple Pub/Sub (BM-SPS).

Bristlemouth Simple Pub/Sub

Because Bristlemouth aims to support microcontroller applications, where resources are often fairly limited, SPS is designed to be flexible and easy-to-use, intentionally omitting some of the rigid characteristics of more fully featured middleware protocols like DDS. The following sections will provide an overview of the SPS's key features, user APIs, and interactions with the lower-level network services.

Key Concepts

Entities Like many middleware protocols, SPS is built around four core conceptual entities:

• Nodes
  • Physically or logically unique software elements that participate in a Bristlemouth network
• Topics
  • Uniquely identifiable resources that nodes communicate about
• Publishers
  • Logical entities that accept data from user code and publish it in relation to a specific topic
• Subscribers
  • Logical entities that receive data related to a specific topic and provide that data to user code

In addition to these core elements, SPS also supports Request/Reply communication with the following entities:

• Services
  • Similar to topics, services are uniquely identifiable resources that implement request/reply communication interfaces
  • Unlike topics, which describe a one-way flow of data between Publishers and Subscribers, services describe a bi-directional flow of data between Requesters and Repliers
• Requesters
  • Logical entities that allow user code to send a request relating to a specific service
  • After sending a request, the Requester expects a reply which is provided to user code
• Repliers
  • Logical entities that allow user code to accept requests, process them, and send replies to the originating Requester that issued said request

Topics and Service Identifiers SPS topics and services are designed to correlate directly with their associated Bristlemouth Resources.

When a user invokes an SPS API to create a Publisher, Subscriber, or Service endpoint with a specific resource ID (such as /my_topic or /my_service), under the hood, the middleware layer invokes the Resource Table APIs to declare a local resource.

Unlike in middleware protocols/frameworks such as DDS/ROS, topics and services are not tightly coupled to a concrete message type with a fixed serialization. Users can send any type of data via Publishers/Requesters/Repliers, though there are some constraints and advice relating to how this should be handled to avoid friction.

Types