Peer to Peer

Welcome to Building Better Developers, the Developer podcast, where we work on getting better step by step professionally and personally. Let's get started. Hello and welcome back. We are continuing our season where we're talking about software architecture patterns and adding patterns. We're going through patterns. In this episode, we're going to look at peer to peer. We've gone through multiple patterns so far, usually I think more like enterprise, but peer to peer can do that as well. It's just, it can also sort of scale down to very simple, one peer to one peer. It's a little different from client server, where you also only have two actors within the pattern. In client server, you have a client making requests of a server. And yes, there are responses that come back, but it's driven by the client. Peer to peer is different. It is a, both of them act essentially as a client and as a server during the use of the pattern. Any peer may end up making a request of another peer and may respond to request from another peer. Most often we see this in networks that need some sort of synchronization. File sharing networks, for example, Bitcoin, crypto type of networks where there are all these nodes and they need to be kept in sync where the data they have to have is the same, regardless of where you touch the network. You see this as well in some of these replication for failsafe type networks and things of that nature as well. But typically it's not, peer to peer is not necessarily going to be like a steady stream of information back and forth where both are doing regular updates. It's more along the lines of, hey, something goes on on this machine and so it's going to make a request to another or send something to the other to say, hey, something updated. I'm going to go ahead and send you the update. Or it may be something where it's peer to peer and before you send a response, if you have peer one and peer two, we'll say, peer one gets a request and maybe it checks with peer two first before it sends a response to say, hey, do I have all the latest data? Like for example, file sharing, do I have the latest file? So it could be a pull kind of thing or it could be a push. So peer two gets a new file and it knows because it's connected to peer one. It says, by the way, this file has been updated. Here you go. And it can be, file sharing is something as an example where it can be rather big, fat, heavy, sizable type messages or transactions that are done from peer to peer. And that's another specialty, I guess, or uniqueness of this pattern is it's really about moving data from point to point. So the peer to peer connection is usually going to be data moving across that pipe, not really requests or responses. Yes, I may request that I get the updated version of this file, but it's really about, I want the data so that I can work on it locally and not where it's a request and say, hey, why don't you go work on it and then send me the results back, which would be typical client server and the client's probably not going to do much work. The server is going to do most of it. So you have a request that goes from the client to the server. Server does the work, generates results, sends it back to the client. Peer to peer, that's not the same. Clients do not exist from so far in what we're talking about. Clients can technically hit any peer and make requests of it. And the peers will respond without needing necessarily to deal with the other peers, because they should all be the same. If you go to five identical people or people that have the exact same job, they should have the same information. If you think about like, let's say a ticket center where they're selling tickets for an event, every phone, every person that you talk to should be able to see which sheets are available, how many seats have been sold, things of that nature. The data that you need for your transaction. That would be sort of a peer to peer, although behind the scenes, it's probably not, let's say there's five people, agents that are answering. They're probably not saying, hey, I sold two tickets. Hey, I sold five tickets. And then everybody manually keeping track of what's going on. There may be situations where something like that does happen, but obviously it would be fraught with the opportunity for errors and miscounts and things like that. There's going to be something that's a more stable store. And in a peer to peer situation, that would be your hard drive or something like that, or file. It could be file sharing. So I make a change. I'm in some sort of a word processor type document. I'm editing the document. And because there's a peer to peer system, while I'm editing it on this one machine, peer one, it gets those changes and says, oh, by the way, this has changed and sends it out to any of the other peers that are in that peer to peer network. And I mentioned peer one and peer two because that's the most simple. But you could have three peers, in which case in a peer to peer, you're going to have peer one can talk to two and to three, three can talk to two and vice versa. And so if you go to five or six or seven nodes, then you start having a huge amount of connections in that peer to peer network because everybody connects to everybody. It's like client server. You may have multiple clients in a single server. Everybody's a client. Everybody's a server. So everything that's every node in the network is connected to every other node. There are other ways that you can change stuff around, but in straight peer to peer, that's what you're doing. Every node is connected to every other node. And so when something happens on a given node that needs to be broadcast, it does. It sends that communication out to everybody. It sends that data. Everybody says, hey, this has changed. Update your whatever it is. And here you go. Now there can be logic to that. If you want to get deep into the crypto coins and stuff like that, and those sorts of networks, then you'll find that they don't necessarily trust each other. So if one peer makes a change, then the other peers are going to get that as sort of like a request. They're going to say, hey, this guy has this changed. Let's validate it. Things like that. And that is a weakness of peer to peer is that it can very quickly get corrupted. So if it's a 100% trust peer to peer network, which means if any node can send every other node and they just automatically assume that that's truth, then as long as all you have to do is corrupt one node and then boom, it's going to corrupt all the others. You have a virus basically that is now infected everything within the network. If you think of a zombie virus simulation type things, if you've ever seen those where you have patient zero and then they contact some people and then they get sick and they contact people and they get sick and blah, blah, blah. Well, this would be everybody's connected at once. So it'd just be like, bam, done. Everybody's sick. That's what a peer to peer network is. And so that's the strength and the weakness of it is that you can have multiple points and at any given point you'll get exactly the same data. The problem is if you get something corrupted, then at every point you're going to get exactly the same data. And you can see this in regional because I've talked about file sharing, but the point behind the multiple file sharing sites and what you see a lot of times when you'll go to a website and they'll have download sites that have all of these mirrors. That's basically what a mirror is. Is it's just, they do it a little differently. It's not really a peer to peer network, but it could be. It could be that when an update goes and that updates to all of the other machines and then you simply, if you want to download a file, you pick the machine closest to you. So you have the less bandwidth that's taken up from point A to point B. Or it's hopefully faster. If you're in Washington, D.C., you're probably going to get your stuff faster if you are hitting a server in Washington, D.C. versus Beijing, China, something like that. So you have geographical type reasons maybe that you would want to have a peer to peer network. There's also, I'll call them environmental considerations at times within a peer to peer network where something that is going on with one peer needs to be known to everything else in the network. So if it's going to be, usually you're using this, like if you're using bots or something like that that have some sort of an external sensor, but it could be the machine itself. The server may be able to do things like measure power draw or heat or some things like that. And it may say, oh, by the way, I'm overheating. And so maybe it's good for the rest of the items in the nodes in the peer network to say, hey, we're seeing overheating over here. So it can be reporting type information as well that is passed then throughout the network. And again, it's so that if you query any given node, technically it can tell you about any other node because they're all kept up to date. Now it is a little bit of a, another weakness is it can be a little bit of a, and are we there yet? Are we there yet? Are we there yet? Kind of an approach where sometimes you get like changes and there's just too much pings or updates that are done across that network. Again, this is something we've seen in the past where we've seen networks have collapsed because of traffic, because you have these things that are acting as nodes and they're, we'll say talking too much, they're sending too much information back and forth. And when you get a huge number of transactions, then of course they grow exponentially. So if one node starts just saying update, update, update, update, well, it's going to do that to every other node. And then every one of those nodes is going to update everything else. And it's, depending on how you do it, you may be, you may be over communicate within the network, but then there may be some other things you can do that are smart to make sure that it doesn't send to a node that's already been sent to. And that's again, not really, not really a peer to peer thing. But what you can do is say, you know, have some sort of protection where a peer says that, hey, if I was updated by from another peer and not from a client, then I'm not going to send an update up update back out. So I'm not going to basically spam the network with update notifications. But if you don't do it right, that can happen. And that obviously is a challenge for that peer to peer network. If you've got a lot of potentially a lot of nodes and anything that you do that's a bug or an error may grow exponentially in the, the cost and the impact of it. So it's one of the things you want to keep an eye out for. Other than that, peer to peer is pretty straightforward, much like client server. Except for in this case, you just, you as a peer, you know who your other peers are. When you have a change of the key things, whatever they are, files or something like that, you send out to everybody else and say, hey, here's the updated file. Not terribly complex, but can be. And the nice thing is though, because it can also be simple for the most part, it is a great way to set up simple networks, simple connections from one machine to another and trying to keep them synchronized. In some case, you'll see some uses again, like, you know, drop box and box and those types of synchronization type tools where you may have, you know, four or five different machines that you really want to keep all your files and synchronized on. They may move up to a cloud and back down. That's maybe a little different, but you could also do it as a pure peer to peer network. There's a lot of information on them. So if you want to see some inaction, if you want to see some good examples, then you can definitely do some searches and find numerous discussions and probably even retrospectives of peer to peer networks that have been built. That being said, we can read. We've reached a good point to wrap this one up. So we will move on from peer to peer. As always, have any questions, shoot us an email at info at developer.com and check out some of these other episodes. And of course, subscribe out on Apple podcasts and you'll get all of the future episodes as they come out as well. But as always, go out there and have yourself a great day, a great week, and we will talk to you next time. Bye.