[From the last episode: We saw how one can send messages to select groups of multiple receivers using multicastA means of sending a message to multiple specific destinations (unlike broadcast, which isn’t specific). or 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..]

Last week, when discussing publish-and-subscribe (pub/sub), we saw how a broker can either push messages out to all subscribers or simply give the subscribers the info they need to pull data on request. That last bit starts to cross into a different way of communicating. People often think of pub/sub as pushing messages to subscribers. Requests to pull data fit a different pattern, called request/responseOne way machines can communicate, where one machine sends a request (or issues a command) to another machine; that other machine responds with data or maybe with an acknowledgment to a command., or req/rep. (Yeah, it takes some imagination to get “rep” out of “response”…)

But this way of exchanging messages extends far beyond pub/sub. We’ve actually hinted at it before, early on, when introducing the notion of a network. It gets to the whole idea of the serverA 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., whose job it is to serve up responses to requests.

Requesting a Web Page

You probably use this way of communicating every day. Every time you click on a website, your computer sends a request to some server. The server is located at the address you specify in the URL (which stands for Universal Resource Locator) after that URL is translated into an IPThis can mean two things (at least):
• The Internet Protocol. Governs the addresses of sources and destinations on a network (without worrying about what’s in between). Used on Layer 3 of the stack.
• "Intellectual property." This can have lots of meanings, but, in the computer-chip world, it refers to parts of a chip design that have been built and optimized by one company, which then sells them to other companies that don’t want to design those blocks themselves. They’re not selling actual chips; they’re selling the design of a block that will be used within a chip.
address.

Actually, the URL is more than just an IP address. The IP address gets you to the server, but the URL also specifically includes what it is you’re requesting: a web page. So your request says:

• “Server at this address,…” (that’s the “xxxx.com” portion of the URL)
• “… please send me this page.” (that’s the “… .com/this/that/the_other” portion of the URL).
• You can even give it some additional hints as to what you want. For example, if you want the English version instead of the Spanish version of a website hosted in Mexico, then you might have a URL like, “www.interesting_site.com.mx/this_folder?english”. The stuff after the question mark provides addition information, or “parameters,” about what you’re looking for.

Before we leave the URL thing, a quick note. How any specific URL works is defined entirely by whomever is creating a website. For instance, for an English version, you could create a separate server, or you could create a separate folder, or you could use a parameter. So this example doesn’t give you the rules of how to do it; it only shows how you can do it*.

Req/Rep in the IoT

OK, so that’s all fine and good, but we’re not here to talk about how web pages work; we’re here to talk about the IoTThe Internet of Things. A broad term covering many different applications where "things"  are interconnected through the internet.. It’s just that web pages are more familiar, and the tech we use for the IoT goes hand in hand with the web-page technology. So let’s look at how req/rep can work for the IoT.

Let’s take the really simple example of a thermostat. It has the job of telling a furnace and/or air conditioner when to turn on and when to turn off (actuation). But, in order to do that, it has to know both what the current temperature is and what the desired temperature is. You tell it what temperature you want using the dials or buttons on the thermostat. But it needs a temperature sensorA device that can measure something about its environment. Examples are movement, light, color, moisture, pressure, and many more. in order to know whether the currentThe amount of electrical flow. Measured in amperes or amps (A). temp is above or below what you want.

So an advanced thermostat may have a temp sensor in it. Back when we saw how sensors are structured, we learned that many sensor chipsAn electronic device made on a piece of silicon. These days, it could also involve a mechanical chip, but, to the outside world, everything looks electronic. The chip is usually in some kind of package; that package might contain multiple chips. "Integrated circuit," and "IC" mean the same thing, but refer only to electronic chips, not mechanical chips. have more than just the raw sensor in them. They also process the raw measurements and then store them. They have a built-in means of sending that data out, but they typically do so only on request. (Hint hint…)

So, every so often, the thermostat needs to check what the temp is**. So it reads the data out of the temp sensor. That is, it’s requesting the temperature, and the sensor is responding with the result. (We won’t worry here about how that actually happens…) Based on that data, then the thermostat can decide whether to turn on the heater, turn on the cooler, or just leave things alone.

If it does need to turn something on – or off – then it sends a message to the heater or cooler. That message is a command, not a request for data. Yet it may still look like req/rep since the equipment may respond with a “Roger that” or a “Success!” or an “I’m sorry, Dave… I can’t do that…”

Req/Rep vs. Pub/Sub

That’s an almost trivially simple example. At the other end of the spectrum, imagine a large, complex factory making dozens of different products. MachinesIn our context, a machine is anything that isn't human (or living). That includes electronic equipment like computers and phones. are constantly interacting, both to exchange useful information needed for manufacturing and so that safety equipment can monitor things and make sure that nothing goes awry.

In order to fulfill their tasks, each piece of equipment might be able to query other equipment for data or to send a command. And, increasingly, such factories may involve large, complex data brokersA server that manages published data and subscribers to that data as part of a publish-and-subscribe setup. – and here we start to blur into the pub/sub region – especially when we want to pull data.

So here’s kind of how we can make a clearer distinction between pub/sub and req/rep, even if we have a broker handling the store of data.

• If a broker automatically sends data updates out to subscribers, then it’s definitely pub/sub.
• If a broker let’s subscribers pull data, but it’s done as part of a group that regularly looks at data, then, even though the subscribers are technically requesting the data, if you back up and squint your eyes, it still looks like pub/sub.
• If the broker can also respond to random requests for data from non-subscribers, then that’s definitely req/rep.

I know, it gets kind of fussy. The good news is that you’re not really going to have to get involved with these distinctions – or the arguments that might happen with people that disagree with how I’ve described this. It just gives you a window into what might be happening under the hood of your new internet-connected toaster. It may be publishing its data to the cloudA generic phrase referring to large numbers of computers located somewhere far away and accessed over the internet. For the IoT, computing may be local, done in the same system or building, or in the cloud, with data shipped up to the cloud and then the result shipped back down., or the cloud may be requesting data from the toaster.

Of course, some machines might get tons and tons of requests… how do they even keep up? We’ll look at that next week.

 

*You might wonder what the heck I’m talking about, since you don’t go through all of this rigmarole every time you go to a website. But, actually, you do; it’s just that you don’t do it manually. Someone has already done the work for you when they created the link that you clicked on. So you can imagine: the simple act of clicking a link sets up a lot of things that happen while you wait.

**To be clear, this is only one way of doing it… older mechanical thermostats would definitely not work this way…