[From the last episode: We saw how we can broadcast a message to everyone in some networkA collection of items like computers, printers, phones, and other electronic items that are connected together by switches and routers. A network allows the connected devices to talk to each other electronically. The internet is an example of an extremely large network. Your home network, if you have one, is an example of a small local network. domain.]

We’ve seen how to send a unicastSending a message to one single destination. message to just one place, and we’ve seen how to spam – er – flood an entire domain with a single broadcast message. But what if you want to send a message to multiple people – but not everyone?

This gets us into somewhat muddier terrain. We’ve entered the realm of multicastA means of sending a message to multiple specific destinations (unlike broadcast, which isn’t specific).. But that starts to overlap with another general approach to sending messages: publish-and-subscribeA way of sending data to multiple destinations. The destinations subscribe to the data using a broker; whatever is generating the data (possibly a sensor) publishes the data to the broker; the broker either sends to the data to the subscribers or lets the subscribers request data., or pub/sub. There are technical nuances to these various things – there are variations to multicast and variations to pub/sub. But, for our purposes, they’re similar enough in spirit to discuss all at once.

One of the major differences we saw between unicast and broadcast was that, with unicast, you know the destination address; with broadcast, you don’t. So… how would multicast work?

Of course, one way to fake out something like multicast is to create an individual message for each of several recipients and send them separately. That would certainly work, but it means lots of messages traveling around, which clogs up trafficRefers to any kind of electronic message -- email, web request, streaming video, or anything else -- that travels over a network.. Might there be a more efficient way to do it?

For things like emails that may happen only now and then (or even only once), no, there’s really not a better way. Things get more interesting, however, when you may have regular messages to send that multiple destinations may be interested in. And this applies in particular to the Internet of Things.

The Challenge of Multiple Addresses

Let’s say that you have a temperature sensorA device that can measure something about its environment. Examples are movement, light, color, moisture, pressure, and many more. in some far-flung locale. It’s there to monitor the temperature, with the ability to report in every, oh, say, 10 minutes. The question is, to whom do you report in?

Well, that depends on who’s interested in the temperature data. And there may be lots of folks that want to know that. How do you get them the info they want without sending each of them a personalized message?

Before we answer that, let’s look at more reasons why being efficient would be a good idea. Yes, multiple messages mean more internet traffic, but it’s more than just that. A remote sensor is likely either battery-powered or may have some kind of solar or other power generation capability. Whatever it is, it probably doesn’t provide a ton of energy. And every message you send takes energy. In fact, turning the wireless radio on to send or receive a message is often the most energy-expensive thing a sensor can do. So sending one message instead of dozens or hundreds makes a big difference.

Another issue relates to addressing. It would be nice if there were a way to put multiple destination addresses in a packetA group of bits being sent from one place to another. How big the group is may vary depending on what kind of packet it is. Long messages -- like an email -- will typically be broken up into many packets, each of which travels independently until it gets to the destination, where they're reassembled into the email. header (instead of just one address) so that, with one packet, you could get to lots of recipients. With some protocolsAn agreed way of doing something. Like a convention, except that protocols tend to be related to processes., that may be possible – for a few addresses. But if you want to send it far and wide, that doesn’t work either; there’s simply not room for hundreds of specific addresses in one message.

Publishing and Subscribing

A final issue is about knowing who wants the data. The sensor system is likely simple and small – for saving energy – and making it keep track of a bunch of people that need the data would be cumbersome. After all, we can’t do something like we did with broadcast, where we dispense entirely with specific addresses. Now we need to be more selective about who gets the message. And the destinations may be in very different places – not all on the same network domain.

So, to deal with this, we split the problem up. We put a server somewhere (presumably where it’s not raining and there’s a nice wall plug) and we tell the sensor simply to send one message to the server: the sensor publishes its data. We call this server a brokerA server that manages published data and subscribers to that data as part of a publish-and-subscribe setup.. Then things get interesting with the server: we take on the concept of groups or topics. This is something that varies depending on what kind of protocol or system you’re using, but the gist is pretty straightforward.

What you do is define groups or identify topics. Then other serversA computer with a dedicated purpose. Older familiar examples are print servers (a computer that controls local printing) and file servers (a computer used for storing files centrally). More modern examples are web servers (the computers that handle your web requests when you use your browser) or application servers (computers dedicated to handling the computing needs of a specific application). Servers are often powerful, expensive machines since they have to handle a heavy load. – really, other potential destinations – can view what groups or topics are available (assuming they have permission), and they can literally sign up for – that is, subscribe to – groups and/or topics. The broker takes care of managing this, and there are a couple ways of doing that.

Pushing or Pulling

One style would be for the broker to maintain a list of all of the subscribers, and, when the sensor publishes new data, the broker can then send out individual messages to everyone that’s signed up. Yup, that’s lots of messages, so lots of traffic, but at least it’s being handled by a nice, comfortable server rather than being foisted on that poor, impoverished, overworked temperature sensor.

In that example, the broker is “pushing” new messages out to the recipients. It’s also possible to do it the other way: have destinations request, or “pull,” updates. In that case, when they subscribe, the broker gives them the information they need to request an update. Such systemsThis is a very generic term for any collection of components that, all together, can do something. Systems can be built from subsystems. Examples are your cell phone; your computer; the radio in your car; anything that seems like a "whole." typically keep a history of data; heck, some of them have very elaborate databasesA structured way of storing data and relating different pieces of data to each other. (Like, which address belongs to which person.) There are “query” languages, the best-known of which is SQL, that let you enter data into the database, change data that’s already in the database, and retrieve data from the database. of all kinds of industrial data that can be requested. (We’ll talk more about requesting data next week.)

Or you could do something in between, with the broker keeping track of network domains that have subscribers and “broadcasting” to that domain with a group or topic name. The servers listening on that domain would pay attention only to messages from groups or topics that they’re subscribed to. That would result in fewer overall messages sent.

There are obviously ways that we could dink with such systems to try to optimize the number of messages sent, but, overall, it lets us be more surgical about who gets messages.