wiki:InterModuleCommunication

Inter-Module Communication

Description

This module is pervasive, and likely used by nearly every other module in some manner. It is not intended for low-latency high-bandwidth transfers, such as a zone database transfer, query processing, etc. It is intended for small status, notification, or other messages to be broadcast to a group of listeners.

The concept is much like what dbus uses, but with more than one machine involved. In general, a message producer need not worry about the actual location of a consumer. For example, "This zone has changed" could be a message sent to anyone interested in that specific zone, regardless of which physical machine the receivers run on.

It should also not be used as a high reliability system, in that a message MUST be delivered to all listeners. Other means to guarantee sync has to be included anyway, for network partitions and so on. However, any optimizations in protocol should be made to assume communication is not interrupted. That is, if a "must verify sync" is needed (think SOA checks) it should be adjusted to not occur exactly once every hour, but perhaps an offset from the last zone update announcements seen on the broadcast channel for that zone.

API outline

  • Each consumer of the API connects to a well know port on the local machine. The location of this port is provided via some sort of "basic configuration" data.
  • Each consumer is assigned a random identity by the communications system. This consists of a random string followed by a host identifier, such as "djlkejfjhkjdhasdkjha@host1"
  • Messages sent always include this identifier, so responses may be sent directly if desired.
  • Groups are implemented to allow a message to be consumed by multiple receivers.
  • A group join request is performed to join a group.
  • Only the members of the group may transmit to it. (Should this restriction be removed?)
  • Group names are created using a principal/instance@host format. The principal is the "group name" (such as "ZoneNotify" for zone notification messages), the instance may be specified or left wildcarded, and the host may be specified for local-to-this-host groups.
  • When subscribing, multiple subscriptions may occur for the same group but with different instances. For example, an auth server configured to serve zone1.example.com and zone2.example.com may choose to only subscribe to those instances. A "zone compile" module may listen on the wildcard, as the data it works with is identical regardless of the instance.
  • The use of principal/instance@host is a convention that each data producer/consumer of that data needs to agree on. This allows flexibility in the API but applies a convention tin how people actually use the API.
Last modified 8 years ago Last modified on Aug 13, 2009, 5:38:44 PM