 Alright, welcome back everyone. This is Brian. We're talking about networking basics. This is basically networking 101. We're going to make a TCP client. Now, what is TCP and what is a client? Well, I'm glad you asked. I'm going to paste just a humongous amount of information on the screen and we're going to go through it super, super quick. So TCP stands for transmission control protocol. It's basically a standard that defines how two machines are going to talk to each other on an IP or internet protocol network. A lot of this sounds super confusing and you start hearing things like three-way handshake and you're like, wait, what? They're shaking hands? Are they friends now? Okay, we're going to dial this back all the way to Newbyland. You have a server which listens for incoming connections. Think of this like somebody sitting next to a phone waiting for that phone to ring. When that phone rings, the person on the other end is going to be speaking a language called TCP. The client is the person who calls the server and is speaking TCP. They both have to speak TCP to talk to each other. Now, once those two start talking, they form what's called a network. A network consists of two or more computers that are linked. When you hear the word linked, really what we're talking about is they can talk to each other. It doesn't matter if they're talking to each other over a physical line, a satellite communication cell phone network. It does not matter. Now, to pull off this feat, they have to use what's called an IP or an internet protocol, which is another protocol. Protocol just defines how things talk. An IP is a number that represents machine on that network. Think of it this way, you have two people talking to each other. How do you know which one is which? We have to name them somehow. So that's really all this is a number that represents that machine. You can have machine one, machine two, machine 500 doesn't really matter. You'll also hear terms like IPV four and IPV six. So four was the fourth version of that protocol. And at the time, they thought they had way more addresses than they would ever use. Well, fast forward and modern times, we are running out of IP addresses. We have so many devices, we are simply running out. So to combat that, they have made what's called IPV six, which will allow everything in the known universe to have multiple IP addresses. You could have network meteors for crying out loud. I mean, it's just a massive amount of numbers. Now you're going to hear things like a port. So basically, every computer can have multiple IP addresses or multiple numbers that identify them on a network or networks plural, but each IP can have multiple ports. A port just defines a channel between those machines where they can talk. This is what I mean by gets confusing. We're going to break it down a little bit simpler, but understand a port is just a communication endpoint that is talking on an IP. The IP is on the network, which belongs to these guys right here, the server and the client. Now, once they're connected and they start talking, they have to use what's called a protocol, which defines a mean of application communications. So what we're talking about here is let's say client call server, but client speaking English and server speaking Japanese, they're not going to understand each other. They need a predefined protocol, which they both agree upon and they both use. All right. So this is a good visual representation of what's going on into the hood. And you as the developer will not see any of this, but you need to understand what's going on. You have a client on an IP address that uses a port and a server with an IP address and a port. This could be the same machine or a different machine all together. For example, I have 120 and 195. These are two different IP addresses. The client is going to send a sin, which is just a special number. The server is going to send that number back with another number called an act. Now when it sends the sin back, I do believe it sends it back modified. So the client knows what to expect. The client's going to take the act from the server and modify and send it back. That way they both know they're talking correctly. They know what to expect. It's kind of like they're challenging each other to give each other the secret answer. Once they both agree, communication is born. And communication can go both ways. You can send and receive data. The first step in any application is, you guessed it, include. So we want to include our logging and we want socket. From there, I'm going to go ahead and let's configure our logging. In case you don't know what any of this stuff is, I highly encourage you to rewind the playlist and watch the previous videos because I've talked about logging in depth. Sockets brand new, but we've really hammered out logging. The next step is we're going to actually create our client. And this may sound horrifying, but it's actually very simple in the spirit of Python. It's very, very simple. So I'm going to say death. I want to make a function called download. And we're going to have a server and a port. Really very simple. From here, I'm going to say s equals socket. And I want to make a socket. From here, we need a family. Now, what do we talk about family? Remember, there's different types of addresses. So I want to say socket.address family underscore, I net. You see, there's I net and I net six. When you see I net, we're talking about IPv4, which we talked about in the previous section, we're going to use IPv4 just because it should work on just about everything. From there, we want to define how we're going to talk. So I'm going to say socket.soc underscore stream. Now this may look like voodoo magic, and you're going to have to take it almost on a leap of faith of what's happening here. But really what we're saying is define a TCP socket using an IPv4 address. And we want that directional communication so we can talk back and forth in a stream of data. Alright, now that we've got this, we can go ahead and say our address. We're going to make a tuple. Just going to be the server and the port. Let's go ahead and say logging.info. And I want to say connecting to our server and our port. And we're simply going to say s.connect. Now this will block. Now this is pretty helpful for newbie entry level, but we're going to do non blocking in the future. But your application is actually going to stop executing at this point. So I'm gonna say s.connect. And we're going to connect to that address. Spoiler alert, this could actually crash your system. We're not using error handling in this video. I just want you to be aware of that. So if you have some sort of crazy error, it's probably because you've chosen a server and a port that is not listening. So we're going to say logging.info connected. Once we've gotten to this point, I want to say logging.send. I'm sorry.info got a little ahead of myself there, just so we know what we're doing. Now we're going to say s.send got a little little ahead of myself. So this is where we have to define what we're going to send to that server. We're assuming that three way handshake took place right here in the s.connect. All of that happens transparently under the hood. But I want you to understand why all of that terminology we talked about exists because if this fails, that means that three way handshake we talked about failed. We're just assuming we've gotten to this point and they've shaken hands and they're now talking to each other in TCP and they know how each other speaks. So we're going to send some bytes, we're going to say hello slash r slash n. So what we're really doing here is we're just sending data. We're not really following any sort of protocol. This is a little dangerous because what if the in server doesn't know what to do with this it could potentially crash that in computer and that actually is a cyber attack where you just send a server a bunch of junk data and watch it die. You have to be a little bit careful when you're in socket land because you can do some really bad things on accident or on purpose. So I'm gonna say logging dot info and we're going to go ahead and receive some data. So I'm gonna say data. Equal this and I want to go ahead and receive up to a maximum of one oh two four bytes. That's our buffer size there. So when you hear buffer really what we're talking about is a a bunch of data and it's limited in size. We don't want to go over that because you can have what's called a buffer overflow, which is a very bad thing if you ever have that happen. But basically your computer would start interpreting that data as raw commands and try to execute it. You don't want to do that. So we're going to limit that buffer here. And now I'm going to say now that we've gotten that data, we're going to go ahead and close this connection down. So let's say logging dot info just so we know what's going on here. Losing and I am overly simplifying this, there may be some folks in the comments that say you really should shut down graceful first, but I'm just going to slam that door shut and let the server figure out what we're doing. And then I'm going to say logging dot info. And we want to know what data we got back from that server, we're just assuming that this whole thing just worked. And there we go. It's really not that hard. Here's our client in all of its glory. We're making a TCP IP for socket with a socket stream. We're got an address of the server in a port, we're going to connect to it assume that three way handshake works, we're going to send it some data, we're not really talking about protocols yet this early in the game. And then we're going to receive some information now this is going to block so we're going to just sit there and wait for the server to send us at least one zero two four bytes. Then we're going to close that socket down. Whenever you open a socket, whether you're listening or connecting, you want to make sure you close that resource, because this is happening in the operating system, which is talking to your network card, you want to make sure that resource is not left open. And then we're just going to print out on the screen, whatever the server sent us. Now that we've defined our client, we're going to go ahead and use it. So we're going to make a main function here. And we're just going to simply call our function. Let's say download and what are we going to download here? Well, this is where some decisions need to be made. And I'm going to use my own website, void realms.com. I really need to update that website. And then we're going to use a port. Now if you know anything about networking, what we're doing is we're going to a website, and we're connecting on port 80. Now this may or may not work. What may happen is we may get some information back, we may get a connection refused. So for example, if I use a port that that server is not listening on, like something like this, it's going to have very, very bad consequences. However, I'm very convinced that at least it should be up and running, or I need to call my ISP and say what the F guys come on. So it's listening on port 80, which is the standard protocol for websites or HTTP protocol. Now notice I said, protocol we're not sending information in a protocol, we're just slamming it with raw bytes. So the server here may come back and say, you know what, I have no idea what the hell you're talking about, go away. It may not even respond, it may just close connection. And you're going to get different results or different servers as we're about to dive in and find out. So let's go ahead and run this, see what happens. All right, so you can see connecting to void realms.com on 80 connected send receive. And it's just hung. It's not doing anything. There we go. So what happened there was my server said, oh, HTTP protocol 11 400 bad request, meaning I have no idea what you're even asking me, bro. Why are you even talking to me? We're not speaking the same language. So this right here is actually a protocol. This is called the HTTP protocol version 1.1. And 400 defines that it was a bad request. And then you get into the very specifics of that protocol. Every protocol is different. Not every protocol is what's called human readable, meaning HTTP is very forgiving. We can pull it up on the screen and read it. Now, if you don't know HTML, that's what all this weird stuff is these little brackets and in brackets. It's all HTTP. This is a web page that we just downloaded. Interesting how this works. So let's actually switch servers here. Let's go from void realms.com to YouTube.com. And let's do on poor 80 and see what happens here. I'm going to go and clear this out. And you know, same thing, much faster though, because YouTube has a lot more money. HTTP 100 400 bad request content type and you get a much different response back. So when in doubt, understand what you're doing here, we are actually connecting to a system and getting information back. But to correctly talk to that system, we now should use some sort of protocol. Now in the beginner videos, we're going to be defining our own protocol. And then as things get more and more complex, we'll be using industry standard protocols. But I want you to really understand what happens here. And let's flip back to our buddy. My server because I don't want YouTube getting mad at me for doing something. I'm going to set it to some port that I'm fairly confident is not in use. And I'm going to just pick a number. I don't have a clue if that's even open. I don't think it would be. We're going to try this. And uh oh, we had an error. So you notice how right here, connection refused. So what's happening here is we're going out to that server, we're performing that three way handshake. And it's saying, you know what? That port's not in use. I'm going to refuse that connection. So that handshake now fails and it sends back the information. And then it goes up through the operating system and into Python and Python tells us, hey, connection refused error. I want you to really understand what's going on there. Just in case you try doing something like that. Now let's try doing something like this. I'm trying to think of a good one. Blah blah. Easy 24.net. I don't think that even exists. Let's clear this out. And we got a different error. Name or service not known. Basically what we're saying is it couldn't even find that remote device because this probably does not exist. Although if you got money you might want to go out and buy that domain name before it gets super popular because blah blah. ZZ24 sounds really snazzy. But I want you to understand the different types of errors you're going to get back just in case you're playing around with this and you can't figure it out. I hope you enjoyed this video. You can find the source code out on github.com. If you need additional help, myself and thousands of other developers are hanging out in the Voidrealms Facebook group. This is a large group with lots of developers and we talk about everything technology related not just the technology that you just watched. And if you want official training I do develop courses out on udemy.com. This is official classroom style training. If you go out there and the course you're looking for is just simply not there. Drop me a note. I'm either working on it or I will actually develop it. I will put a link down below for all three of those. And as always help me help you smash that like and subscribe button. The more popular these videos become the more I'll create and publish out on YouTube. Thank you for watching.