Message Broker Communication

An alternative to direct node-to-node communication is to use a single message broker for all node to node communication. The advantage of this method is that nodes do not need to accept inbound connections from other nodes which makes certain deployment scenarios easier to implement, for example the case where more than one of the MPC nodes run on mobile devices.

Currently AMQP is the only supported protocol, and it has only been validated when using RabbitMQ as the message broker.

To configure a node to use AMQP you need the following section in the configuration file of each node:


  # URL for the AMQP message broker
  # For a local test instance with the default vhost and guest user the following URL can be used:
  # amqp://guest:guest@localhost:5672/
  ServerURL = ""
  # When connection to the broker drops or sending of a message fails, how long should we wait before retrying
  RetryDelay = "5s"
  # Specify how many channels should be used when sending messages to the broker. You might want to increase this value
  # if you enable PublisherConfirms below.
  ChannelPoolSize = 2
  # Use the RabbitMQ specific publisher confirms feature. This configures the RabbitMQ server to confirm each message
  # before that message is considered delivered by the client. This makes the communication with the broker more
  # resillient when the broker restarts or the network connection fails during a session, but it also has a performance
  # impact.
  PublisherConfirms = false
  # Instruct the message broker to persist messages. If using durable queues this ensures that messages will survice
  # a restart of the broker.
  PersistMessages = false
  # If SkipSetup is false the client will automatically create exchange and queues on the broker. However, if you need
  # more control over who can send and receive messages set this to true and configure the broker like this:
  # First you need to know how to get the player ID of a player. The player ID is computed by first using SHA-256 to
  # hash the public key and then base64 URL encode (without padding) the output of the hash function.
  # 1. Create a direct exchange with the name
  # 2. Create a queue for each player with the name tsm.playerID and an  x-message-ttl of session timeout + connection timeout
  # 3. Bind the queues above to the exchange with the queue name as the binding key
  # 4. Grant all users write access to the exchange
  # 5. Grant all users read access to their own queue
  SkipSetup = false

When using a message broker, the MPC nodes secure the communication using encrypt the communication using the private and public keys specified in the configuration files, so the AMQP server is not a single point of trust, even if TLS connections are terminated at the message broker.