More content to follow...
The purpose of supporting UDP is for multicast, or in other words, broadcast publishing of information. One typical use case is a UDP multicaster service that needs to know what to multicast in behalf of other services. This is the combination of Point-to-Point Channel and Publish-Subscribe patterns, and a form of Message Router. Thus, our UPD multicast is a use-case-specific component, although it can be used for basic UDP multicast of foreknown information.
The vlingo/wire component
MulticastPublisherReader is both a UDP multicast publisher and a TCP socket reader (that's the
Reader part of the name). The client of the
MulticastPublisherReader takes a
ChannelReaderConsumer as a constructor parameter, and when it receives TCP requests it relays the requests to the
ChannelReaderConsumer. Why? Because the
MulticastPublisherReader only knows how to publish two things:
It's own availability, which it does by multicasting its own TCP address, which it holds in its
publisherAddress instance variable. This TCP address is how other services can tell it what to publish, which leads to...
Whatever its client tells it to multicast. This is done via its
ChannelPublisher protocol method
void send(final RawMessage message). These are received via TCP requests, for publishing of the information in the
RawMessage. One example of such is registration by services that want their availability know to other services.
The best place to see this in use is in the vlingo/directory service and its main processing component
This is where vlingo/cluster and UDP multicasting meet. The
DirectoryService protocol includes
assignLeadership(), which is how a given vlingo/directory cluster node knows that it is in the lead and is the active UDP multicaster/publisher. Any other cluster nodes are standby in case the leader node is lost for any reason. A
DirectoryClient, which is any service that wants to register and/or discover via the vlingo/directory, sends and receives availability information in the form of
ServiceRegistrationInfo by supporting the
io.vlingo.directory.model.DirectoryApplication, which is a
ClusterApplication via the
ClusterApplicationAdapter, informs its own
DirectoryServiceActor to go into either active or passive mode. Active mode is described above. Passive mode is any cluster node member that is not the leader. These (most typically 2 of 3 nodes in the cluster) simply collect publishable data that the leader receives. The leader tells them this via the cluster
AttributesProtocol attributesClient. This means that the leader uses the cluster-wide attribute publishing facility to share registration information with all passive nodes. If the leader is lost, then a passive node will be elected as the leader, and already has most or all of the current registration information. Any lag in current registration information will soon be cleared up when directory clients begin live (pulse-based) updating to the new directory leader.