[From the last episode: we saw how load balancingA way of handling heavy server traffic by having multiple servers that can do exactly the same thing and then using another server as a dispatcher to assign tasks to the least busy servers. helps 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. keep up with high trafficRefers to any kind of electronic message -- email, web request, streaming video, or anything else -- that travels over a network. demands.]

Today we give you a million-dollar new vocabulary word (with an extra bonus if you already knew it). Before we give it away, however, let’s run through a couple of scenarios to illustrate the concept and why it’s important.

Where’s My Web Page?

Here again, we’ll start with the more familiar web-browsing world before moving to the IoTThe Internet of Things. A broad term covering many different applications where "things"  are interconnected through the internet.. Let’s say you go to your browser and surf to a particular web pageA chunk of memory on a hard drive or SSD that can be brought into DRAM for use or for execution.. As we’ve seen, your browser is sending a request to that site for the contents of the page, and the server responds by sending back the page.

But, in case it’s not obvious, there’s no guarantee that your request will get to the server. And there’s no guarantee that the response will get back to you. Why? Because basic web surfing uses a “best-effort” service (UDPUser Datagram Protocol. A “best effort” (i.e., no guarantees) way to get a message from one place to another. Used on Layer 4 of the stack. – User Datagram ProtocolAn agreed way of doing something. Like a convention, except that protocols tend to be related to processes.). In other words, “we’ll do our best to get your message to the destination, but if we run into trouble, it may not work.”

Things have improved in recent years, but you may still find (or you may remember) trying to get to a website and nothing happening. So… what do you do? You click the link again, and, magically, it works.

The key takeaway here: clicking the link twice doesn’t affect the response you get. Heck, even if you got it the first time, doing it again shouldn’t matter. (OK, assuming there’s not something that randomly changes on the page…)

How Much to Cut?

Let’s take a different example. You’ve got a machineIn our context, a machine is anything that isn't human (or living). That includes electronic equipment like computers and phones. that you can remotely instruct to make cuts to wood. You’re doing something experimental, and you made a ¼-inch cut, but you decide you need to cut another ¼ inch. Let’s say you’re using your phone to send the commands, and it instructs the machine to make the extra cut. Sounds straightforward, right?

Well, let’s say that this system works by having the saw send an acknowledgment after the cut is complete. Problem is, this time, you get no such response. Should you simply repeat the request and hope for better results the next time, like you did with the web page request?

Let’s think that through. Let’s say that the reason it didn’t happen was because the request never made it to the saw for some reason. Well, if the request gets there the second time, then the extra cut is made, and you should be good.

But what if the problem is that the cut was made the first time, but the acknowledgment never made it back? Now, when you send the second request, it’s going to cut another ¼ inch on top of the extra ¼ inch it just made (but didn’t tell you about). Now you’ve cut too much!

Or maybe the machine itself broke down part-way through the cut (let’s say the blade passes back and forth shaving a little each time and didn’t make it all the way down). Now you have your cut partially done, but… you don’t really know how much, so you don’t really know what to issue as the next command after the machine is fixed and starts back up.

Million Dollars

And that brings us to our million-dollar word: idempotenceA property of a command or operation such that doing it once or more than once yields the same result.. An idempotent command, put (over-?) simply, means that you can issue the command once or more than once, and the result will be the same. That’s what happened with the web page: if it didn’t work the first time, then doing it again is, of course, ok – even if it turns out that your request did get there the first time (and you just didn’t get the response).

The wood-cut command “Cut ¼ inch” isn’t idempotent, since doing it once and more than once are definitely not the same thing.

Yeah, I know, it sounds like some way-out-there abstract math concept, but, for the IoT, it’s important. SystemThis 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." designers need to think through what might go wrong to make sure that the way they design things is robust in the face of very possible connectionThis refers to some kind of electrical connection. It might be through a network cable, a cable connection, a wireless connection, or a phone - just to name some options. The connection might be to the internet or to some other local device. (and other) failures.

So… instructing a machine to cut ¼ inches sounds pretty obvious. If you can’t do that, what can you do? Well, instead of specifying how much to cut, you can specify how deep you want the resulting cut to be. Instead of commanding, “Cut another ¼ inch,” you command, “Make the cut ½ inch total” (since you had already done a first ¼-inch cut). Now it doesn’t matter how many times you send the command, you should end up with a half-inch cut.

That means that you need to know not only how much to cut now, but also what the depth already is. That might involve a sensorA device that can measure something about its environment. Examples are movement, light, color, moisture, pressure, and many more. to detect the depth. Or perhaps the machine logs each pass of the blade in a databaseA 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. so that it can review what it’s already done in order to calculate how much more needs doing.

Yet More to Go Wrong

Of course, everything you add – like a database connection – is yet another thing that could go wrong, so truly robust system design takes a lot of thinking through. We’re not going to get carried away with that analysis here, but I thought it useful to show some of the thought process that has to go into IoT devices.

And, with the number of companies trying to beat everyone else to market, it’s a pretty fair bet that not all of the gadgets will get that thorough thought process. And, with many devices, it probably doesn’t matter. But if you’re buying something that can affect your safety – like even a door lock, you want to know that it can handle some of the unfortunate things that can trip up any system if it’s not designed well.

This isn’t going to be something you can ask a salesperson, so it’s not something going onto the purchase checklist, but it’s something to keep in mind. (Or it’s simply something interesting for the curious mind.)