BlueDragon 7.0: new tag CFMULTICAST

With the release of BlueDragon 7.0 just around the corner, I am going to go through some of the new functionality and tags that we've introduced.  Many of the new tags are centered around giving the CFML developer greater access to external resources and services.  For example the first one that I am going to look here is the <CFMULTICAST> tag that is used to both listen and send to multicast networks.

For those that don't know what a multicast network is don't worry it is not too complicated.  It is a way to broadcast data on a network where by only one copy of the data packet is transmitted but many receivers can read the data packet.  For example, say you wanted to broadcast an MP3 file to 100 people in your network, then using traditional methods you would have to send 100 copies of the same file, utilising a lot of bandwidth in the process.  Using a multicast address you would only need to send one copy of the file and everyone would read that copy, thus dramatically reducing the bandwidth overhead.

Okay that is an extreme example, so let us look at something closer to our CFML hearts.  Assume you have a pool of servers running in a cluster then using a multicast address you could broadcast messages to everyone when an event took place, say when someone updated content you could broadcast that change so all the servers where up to date.  You aren't restricted to just CFML-2-CFML communication; there are many Linux utilities out there that will broadcast their runtime state, allowing you to listen in.  Maybe you could create a CFML application that watches and generates an email when one of your Linux boxes reaches 90% disk full.  The possibilities are endless.

So let us look at what the <CFMULTICAST> tag brings to the party.

There are two modes for this tag; broadcasting and listening.  First transmitting.  Consider the following example:
  <cfmulticast action="send"
cfmldata="#cgi#" [or textdata=""]>

This takes the attribute cfmldata, converts it to WDDX, and broadcasts it out on the multicast address on port 17000.  Any process listening on that address will receive the WDDX data.  If it is another BlueDragon instance, then it will automatically deserialise the WDDX packet converting it back to a CFML structure.  Very easy.

So let us look at the other side of the fence; receiving multicast data.

  <cfmulticast action="listen" 
cfc="mycfc" cfcfunction="doAction">
This need only be called once and when completed any message received on that address will automatically call the method 'doAction' in the 'mycfc' CFC.  This is a single argument method that will pass in a structure with various meta data regarding addressing.  If this packet represents a CFML structure, then the key .cfmldata will exist, otherwise, it will simply be .textdata.
  <cfmulticast action="status" address="" port="17000">
In addition, there are a number of other tricks up the CFMULTICAST sleeve. One of them is the action=status.  This returns back a structure showing you various runtime statistics on what has been happenning.  This tag also maintains its own multicast.log file that details any errors and all actions.

This tag has been in production use for many months now on the Blog-City platform where it replaced the CFMESSAGE JMS implementation.  There was nothing wrong with CFMESSAGE, just JMS was too heavy a process for the job of simply passing around short events.

The CFMULTICAST tag will prove useful to those in clustered environments or for those wishing to write monitoring applications and will be available within BlueDragon 7.


Recent Cloud posts

Recent JAVA posts

Latest CFML posts

Site Links