Tower Defense: How TCP Packets Work

so we need to talk about the TCP part of the Tower Defense so if you haven't seen the Tower Defense thing I'll put it in the description it's the higher level overview of the project but a lot of people asked about how does the TCP side of things work so I'm going to kind of walk through that in much more detail than I was all right so the first thing you need to understand oh look at that we have twitch chat up there get the hell out of there all right so the first thing you need to understand is that you don't have to understand how TCP Works to use it the things about TCP that are very very important is one it can take a lot of data and it can send it across uh the internet this is very very important I'll explain why here in a second and two it is reliable and in order meaning you can send structured data this is very very important for our game now a lot of people are going to ask why not UDP well really I just don't have time to build all of everything and UDP is hard to do one thing that UDP doesn't do is it doesn't do all of the data instead you have to send out a packet of data you cannot send out all the data you want just one packet you have to control the packets on both sides second it's not reliable it's not in order that means you have to build reliability and order into the protocol that's used with UDP but the thing about UDP is it's very very fast it's stateless you just start shooting data towards it and with TCP you have to do like this three-way handshake and it's just a little bit slower there's also a lot of AXS within it where whereas with UDP you can kind of design how you want to be reliable RTP is a good example of this all right so with that in mind whenever you send a bunch of data Let's Just Pretend We're going to send a big old Json object full of stuff and this is say 10K worth of data all right let's just pretend it's in a string now you can imagine all of this is just asky character so it can directly be a memory buffer when I send this in TCP you can imagine that I'm going to chunk it out maybe let's just say we're chunking it out 1K at a time how much data you can put per p is called the MTU the MTU right and MTU is called the maximum transmission unit uh Network there we go and this will tell you how big you can send packets across the internet typically I see a lot of things say either 14 or 1500 there's like specific answers 1472 or whatever it is don't worry about that for now let's just say that we send 10 uh or 1,000 bytes at a time that means our 10K package becomes 10 TCP packets what TCP is going to do is send each one of these pack out and inside the packet header they're going to have something like a check sum so that way in case things go bad on the internet we'll know and then they'll also have an index this is index one this is index two this is index 3 and they will piece back together the message to me and start piping it out but here's the deal the meaning of the data is on me the order and reliability and the structure of the data is on TCP that means if I send out one two 3 4 five TCP may send out 1 two three in one packet and then four and five in another packet and I will receive potentially two Network calls that let me know that I've received 1 two three and that I've also then received four and five it's up to me to put these together and do something with it so this is where we get into how our protocol actually looks so the protocol that we've done right now is a very very simple one the very first bite of anything I send is going to be the version this is super super important if you ever do any sort of binary anything just remember to always put a version flag in there so if the first bite I read isn't the version I expect I cannot parse this packet I don't know it get it out of my face the next one is the command this is going to tell me how I need to parse the rest of the data Okay the third one is going to be the length and this will be two bytes just in case we need to make the length long enough to be able to you know part you know like if I have to send a whole board with the data that's going to exceed one bite one bite is 250 56 uh possib possible values which means uh an MTU could be huge right the packet I could be sending could be 10K I can't represent that but with two bytes I can represent up to 65k which is a tons of data I'm never going to send something that large and then the rest of it is going to be the data okay so let's kind of go through how this parsing actually works really quickly so it's pretty pretty simple if I start reading here in fact I believe I have the code right here there we go so I have the command if I want to read the data I'm going to get a bytes array in I'm going to check the first one is the version true no it's not I'm done I'm aired I cannot do this next I'm going to read which is called Network order or big Indian I'm going to read Network order bytes two and above and I'm going to read 16 bits or two bytes now remember if you remember our previous one we were just looking at uh where are you where are you we do two bytes to length starting at the second bite and so you can see it right here the second bite right here okay and then I go okay here's the end the end is going to be the header size which is four bytes plus the length of data and that makes sense cuz again this is length data this is four bytes one for version one for command one for length uh I don't know why I keep going back to here uh anyways so if our length isn't long enough we can't process this packet of data we can't do anything with it else I say the command is the first bite the data is from the header size all the way to the end store these two things and I've just unmarshal that binary data into the TCP packet and turning it into binary data is also really simple because I just simply take the length of the data that's the length I make that into a little bit of a binary thing put the utf16 in there next I make another binary packet where I put the version as the first bite the command as the second bite spread the two bytes in for the length data and then spread the rest of the data in just like this I just did the inverse operation of parsing in it's pretty straight forward and so that's all I have to do so as I get all this data coming in I just simply have to read out and until I hit a packet that I can process now the cool part is if I look under connection I believe this is uh there we go it's pretty simple I made a pretty simple little frame reader so I try to follow the uh uh IO reader uh interface just to make it so that it's easy to interface with other people but what I did here is that I have this I have I'm going to read some data and I'm going to return out to you an INT and an error the first thing I try to do is take my previous amount of data that I have cuz imagine you sent me enough data that I could actually have like two packets in a sing SLE data that you sent me well I'm going to take my previous data that I've so far stored and see can I parse out a packet if I can parse out a packet well guess what then I'm going to use that data and hand it back I'm going to copy out my previous into the data and hand back that okay here you go if I don't have enough data I'm going to wait on re that means I'm waiting for TCP data to come in when that data comes in I just append it to my previous and then go in this Loop so every single time I just keep running this Loop and until I have enough data to parse out one packet and then I return that bite array and say Hey you can read this now which means that the thing that's producing the TCP packets when I call read on my connection it actually gets out the perfect amount of data to be able to read a TCP command every single time so it's just really simple to use and I just thought this was a lot of fun to do super super neat uh learned a lot I made so many stupid mistakes with go oh my goodness I'm learning go the amount of times I made mistakes with just like any sort of like a you know an array of connection and I was still using connections that I wasn't meaning to use and all this kind of stuff and and how coping works and all that and it was just a heartache I'll tell you that much I was hurting but we got over it everything's working great and if I jump over here and I go back to this I'm going to start my server really quickly and then I'm going to go right here you'll notice that right here you'll notice that the game is starting to play right here and these windows are just randomly opening and closing and now the game is remaining insane and playing across all four Windows even though we're disconnecting and reconnecting randomly so it's pretty cool I'm really really happy with where things are going and so the next kind of few streams I'm going to be doing is really just focused on how do I send color down because that's where things get really difficult because I want to be able to send down as little data as possible to the point where I'm only sending down maybe 200 500 1,000 bytes worth of data to represent all these different screen changes and I have to be able to include color it's going to be a little bit difficult but we're going to make it work and I have never been more excited so I hope you enjoyed this I hope you enjoyed this little bit more Deep dive into what I'm working on the color stuff is going to be a lot harder we'll see how it goes but I think I'm going to be successful here the name it's the prime

Channel: TheVimeagen

Views: 34,711

Keywords: software engineering, software, vim, bash, rust, vtuber, programming, programming live, live coding, coding, developer, developing, web dev, web live coding, rustlang, golang, typescript, javascript

Id: 4NjE86ur-ck

Length: 8min 52sec (532 seconds)

Published: Fri Apr 12 2024