146: Distributed Computing: It Happened When?
Take Up Code - A podcast by Take Up Code: build your own computer games, apps, and robotics with podcasts and live classes
Categorie:
Computers rely on clocks. They coordinate everything. But the clocks on different computers can be slightly off from each other. This is normally not a problem. Until you need to merge rapid events from multiple computers and put them in order. You have some options and I’ll explain those in this episode. Let’s say that you have a file backup service that’s busy protecting your documents by copying your files online. This is a form of distributed computing and I’ll describe a real but unlikely scenario involving timestamps. I say unlikely because you really have to go out of your way to do this but it is possible. And because it’s possible, it represents the type of design decisions you need to make as a software developer. Dates and times are tricky enough on a single computer. Adding multiple computers takes the problem to a whole new level. Listen to the full episode for more insights and tips for dealing with dates and times across multiple computers. Or you can read the full transcript below. Transcript This is normally not a problem. Until you need to merge rapid events from multiple computers and put them in order. You have some options and I’ll explain those in this episode. Let’s first think about cases where this is no problem at all. If you create a document on your computer, then it gets a creation date and a modified date. After all, creating a document means it also gets modified. Then anytime you make additional changes, the modified date changes. How precise do you need these dates to be? Normally, I’d say a date and time down to the nearest minute is good enough. Probably more than enough. Dates and times are a lot more complicated than might first appear. I devoted a full five episodes explaining them. Make sure to listen to episodes 118 through 122 for more information. And episode 117 about the decimal data type talks about precision. The reason I say that a file date and time down to the nearest minute is good enough is that usually our need for precise timing information decreases over time. When you first save changes to your document and go back to look at the file information, it’s important for it to show that it was just updated a minute ago. Otherwise, you might think something was wrong and that your changes didn’t get saved. A week later though, and maybe just the hour is all you need to know. Maybe you just want to check if you last updated the document before or after an important meeting and you just want to check if the document was last changed in the morning or afternoon. A few months later, and you’re probably only interested in the date. That’s what we need. Computers are different. A computer needs precise dates and times always. So a computer will record when something happened with a lot more precision than it usually displays to us. Now, let’s say that you have a file backup service that’s busy protecting your documents by copying your files online. This is a form of distributed computing and I’ll describe a real but unlikely scenario involving timestamps. I say unlikely because you really have to go out of your way to do this but it is possible. And because it’s possible, it represents the type of design decisions you need to make as a software developer. Imagine you have two computers both connected to the same backup service and the system clock is about five minutes ahead on one of your computers. That’s not very much and within reason. Now, you go to the computer with the later time and modify a document. Let’s say you modify the document right at 1 pm. The online file gets updated. Then you go to your other computer with the early time and modify the same document but with a different change at 12:56 pm. It took you a minute to switch computers. The question becomes, which document should be the latest version online? Should you use the newer document that was modified pre