Last updated 18 days ago

Wire protocol full-duplex TCP and UDP multicast messaging implementations.

TCP Support

More content to follow...

Practical UDP Multicast

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:

  1. 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...

  2. 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 componentio.vlingo.directory.model.DirectoryServiceActor.

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 ServiceDiscoveryInterest protocol.

Ultimately 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.