Negotiating Publisher

The negotiating publisher will select zero or more supported message types (zero when publisher and subscriptions have incompatible supported message types). To do this, the negotiating publisher performs the following steps:

1. Use discovery to find all the connected subscriptions that are using the user specified negotiation topic.
2. Receive the supported message priority maps from all connected subscriptions.
3. Decide the selected message types by considering the supported message priority maps of the publisher itself and of all subscriptions.
   • This can result in zero or more matches, as mentioned above. In the case that there are zero matches, an error should be returned.
   • While there is a built-in negotiation algorithm that works for most cases, the user can also provide a custom negotiation algorithm.
4. The negotiating publisher then creates a regular publisher for each supported message type.
5. Notify all of the connected negotiating subscriptions of the selected message types.

Negotiating Subscription

The negotiating subscription will send its supported message priority map to the negotiating publisher and then wait on the negotiating publisher to tell it the selected message types. Upon receiving the selected message types from the negotiating publisher, the subscription will choose the match with the highest priority in its own supported message priority map. In the case that the multiple messages are of the same priority to the subscription, the negotiating subscription will choose a selected message type randomly. The negotiating subscription will then create exactly one subscription corresponding to the chosen type and topic name.

Negotiating Publisher and Subscription Pair

The negotiating publisher and subscription pair is a single node that has both a negotiating publisher and subscription. In this case, the negotiating subscription will wait on the negotiating publisher to pick selected message types and then make it's supported message priority map based on the publisher selected message types. Doing so allows the negotiating subscription to prioritize the selected message types of the publisher, which may be desirable for efficient data transfer.

The negotiating publisher and subscription pair operates much as described in the previous two sections, with one exception: the negotiating subscription will delay revealing its preferences until the negotiating publisher has determined its type. At that point, the negotiating subscription will reveal its preferences, and take part in the upstream negotiation network.

Renegotiating Selected Message Types

In the case that the ROS 2 network is changing, the negotiating publisher may need to renegotiate its selected message types. The process looks similar to the original negotiation, however the negotiating publisher remains active until it determines that the selected messages must be changed. If the selected messages must change, the negotiating publisher destroys its publishers. The negotiating publisher will then notify its subscriptions of the new selected message types on the user specified negotiation topic and create new publishers for the selected message types. When there is no change required in the selected types, the publisher will continue to be active.

Similarly, the negotiating subscription may need to change its selected message type. Once the negotiating publisher relays the new selected message types, the subscription decides if it needs to be updated. If the selected type or types match the subscription's current selected message type, the subscription does nothing and continues to be active. If the selected type or types do not match the subscription's current selected message type, the subscription recreates the subscription with the new select message type.

User Defined Functions

There are two types of custom functions in the negotiation process that the user can define:

Simple Examples

We can now use this notation to reason about the agreed upon the selected message type in several different scenarios. There are several cases that are clear.

(1a)
                 x
        N_1(x) ----> N_2(x)

(1b)

        N_1(x) ----> N_2(y)  # FAILED NEGOTIATION

(1c)
                 y
        N_1(y) ----> N_2(x, y)

(1d)
                 x
     N_1(x, y) ----> N_2(x)

(1e)
                 y
     N_1(x, y) ----> N_2(y)

(1f)
                 x
  N_1(x, y, z) ----> N_2(x, a, b)

(1g)
                 x
  N_1(x, y, z) ----> N_2(a, b, x)

Publishing to Multiple Nodes

There are also the cases where there are more than two nodes.

In the following case, N_3 has the limiting supported type, y, so N_1 will publish y, despite the fact that both N_1 and N_2 prefer x. This is assuming that the function for picking the selected types prioritizes sending one message over sending multiple messages.

(2a)
              y
  N_1(x, y) -------> N_2(x, y)
                 |
                 |-> N_3(y)

In the following case, the two nodes receiving data from N_1 both require different supported message types. Thus, N_1 has two selected message types, x and y, and thus N_1 has two publishers.

(2b)
              x
  N_1(x, y) ----> N_2(x)
          |
          |   y
          |-----> N_3(y)

Negotiating Publisher and Subscription Pairs

To discuss negotiating publisher and subscription pairs, we'll have to use additional notation. The following notation shows the result of a custom function that uses the negotiating publishers selected message type to decide the supported message priority map for the negotiating subscription.

Let N_p([x, y, z], {x: [x, y, z], y: [y, z, x], z: [z, x, y]}) be a node p thats negotiating publishers and subscription. The first argument [x, y, z] is the prioritized supported type map for the negotiating publisher, that is, in this case, the negotiating publisher prefers x more than y, and y more than z. The second argument {x: [x, y, z], y: [y, z, x], z: [z, x, y]} is the prioritized supported type map for the negotiating subscription. This second argument is in the form of a dictionary ({key1: value1, key2: value2, ...}), where

• the key is the selected message type of the negotiating publisher in the negotiating publisher subscription pair and
• the value is the prioritized supported type map for the negotiating subscription given that key.

For example, for the node N_p([x, y, z], {x: [x, y, z], y: [y, z, x], z: [z, x, y]}), if the negotiating publisher negotiates with its subscriptions and determines that the selected message type is y, then the negotiating subscription in the negotiating publisher/subscription pair will state its supported message priority map as [y, z, x]. This is because in the second argument (the negotiating subscriptions preference map) the key y is mapped to the value [y, z, x]. Similarly, if the publisher chooses z, then the subscription will use the supported message priority map of [z, x, y].

As a shorthand in figures, we'll define a node that differs its preference beforehand and add an asterisk to separate it from other nodes. For example:

N_p*(x, y, z) := N_p([x, y, z], {x: [x, y, z], y: [y, z, x], z: [z, x, y]})

or

N_p* := N_p([x, y, z], {x: [x, y, z], y: [y, z, x], z: [z, x, y]})

Also, note that regular nodes with the standard notation (e.g., N_n(x, y, z), with no *) reveal their preferences when queried.

(3a)

  N_2*(x, y, z) := N_2([x, y, z], {x: [x, y, z], y: [y, z, x], z: [z, x, y]})

                 y                   y
  N_1(x, y, z) ----> N_2*(x, y, z) ----> N_3(y, z, x)

This approach can also be useful in networks that contain loops. In the case below, node 2 will cause node 1 to wait to pick its preference until it has determined its selected message type.

(3b)

  N_2*(x, y, z) := N_2([x, y, z], {x: [x, y, z], y: [y, z, x], z: [z, x, y]})

                  y
               |--------------------------
               |                         |
               |                     y   v
  N_1(x, y, z) ----> N_2*(x, y, z) ----> N_3(y, z, x)

It is possible with this method to have a deadlock. In the following case all nodes will delay their preference indefinitely. In this case, the only way out will be a timeout.

(3c)

  N_1* := N_1([x, y, z], {x: [x, y, z], y: [y, z, x], z: [z, x, y]})
  N_2* := N_1*
  N_3* := N_1*

    -- N_3* <--
    |         |
    v         |
  N_1* ----> N_2*

Notice, however, that the deadlock is fixed by one node readily revealing its preferences.

(3d)

  N_1* := N_1([x, y, z], {x: [x, y, z], y: [y, z, x], z: [z, x, y]})
  N_2* := N_1*

    -- N_3(x, y, z) <--
  x |                 |
    v    x          x |
  N_1* ----> N_2* -----