Tower Defense: How TCP Packets Work 

YESSSSS

Where is his course?

Finally, no random 1-2 year ex-F or tech leads teaching some random leetcode, useless non-context system design question, written from their official pass-interview books, or tutorial stuffs, and "constantly unintentionally" mention it can get you into Big tech like them. I was expecting someone from Big tech to fill the gap for this type of contents, and truly show the ability of Big tech engineer (like how we admire their technical ability in the old time besides salary), but didn't expect it took such a long time to have one like Prime.

Netflix btw

agreed

does this work with coconut shower gel, too? i have some of that..and need to learn more about coding! :)

Yes, but we are solving it generally. Sending diffs down

I'm in a similar funny scenario: the professor told us to make a matrix solver, so I started by making a program that takes a solution, generates a matrix, and feeds it to the other program to solve it, and then I check if I came full circle. I like how paradoxical it sounds from afar

I think I accidentally may have made an educational video

Because you may read more than one frame, I need to keep storing whatever remaining data is left until the next call to read

​@@TheVimeagen In other words this means that a command may span over multiple frames (i.e. TCP packages), right? You also said this in the video. What is confusing to me is that inside of conn_Next() (one call of which corresponds to one command) you're only calling c_Read once. Because of that I'm not exactly sure I understand how this works in case you need to do multiple calls to read for one command. The only potential explanation I have is that the TCP Reader abstracts away from you the actual structure of TCP packets and just Reads every time you ask it to, so you effectively: -hand a 1024 byte scratch to FrameReader_reader (which is net_Listen behind all the interfaces) -check if what it wrote there combined with t_previous resembles a complete VimWithMe Packet -if yes (n>0) copy the result to data bytes[] -othewise just do another iteration of f_reader_Read But in this case, again, I'm not sure why would you need to access t_previous from a different FrameReader_Read() execution.

​@@TheVimeagen dang it, no matter what I do, it seems that youtube deletes my reply every time :( it's only visible with the "sort by newest first" view

There are some things that are unencrypted when it comes to TLS and HTTP There are some things that are not. There are now more and more secure algorithms that are being used. Secure DNS as an example

TCP handles the guarantees that you'd want to have to deem your communication is reliable. It guarantees in-order delivery, retransmission of dropped packets, and de-duplication of packets. HTTP is concerned with the contents of the communication between two parties. Like, if I introduce myself "what's your name", convention is to respond with your name and maybe a gesture like a handshake. In the same vein, there are always required headers from the client like the HTTP method, and even if the server doesn't respond with a body, it still needs to respond with a status code like 200, 303, 404, 500 so the client ( usually a web browser ) knows how to process that. In order for clients and servers to be able to understand each other, there have to be some defined elements that are always present in each message, and HTTP governs what those parts are. In other words, HTTP defines how what plain text communication should be sent between two parties in order to have a meaningful conversation. As for HTTPS, that just means your HTTP connection is using TLS ( transport layer security). One of the 3 reasons is the one that you mentioned; if someone is packet sniffing it doesn't matter because the message has been encrypted. The other two parts is for clients to be able to trust that the server they're making a connection with IS ACTUALLY the entity that they say they are ( what good is encrypting messages if I'm unknowingly connected to a bad website. The last part of TLS is that you have guarantees that your message wasn't tampered with ( think of the tamper seals on food, for example ). The short version of this is: TCP: how do we deliver data "reliably" over an unreliable medium HTTP: what kind of structure / form should our text messages between us take? HTTPS (TLS): how do we make this data transfer secure?

In tcp yes

@@TheVimeagen Many consumer lever routers fuck up the checksum though.

Gimp

HTTP is the application layer. TCP is the underlying protocol that allows HTTP function. So basically HTTP is TCP with extra steps

PrimeTime is more for his reactions videos and such. This is more of a coding showcase. I can see why he wouldn't want to upload this on PrimeTime.

No one is arguing with you, I just have limited time

@@TheVimeagen I agree with the time statement. I'm not a full on developer so I don't have a direct solution. I am an SRE by trade and just know from studying this issue for performance reasons, that TCP protocol if missing packets will start to snowball into a starve situation. I really like your packet version control, i think that will significantly improve your efficiency. I would say don't change anything just think through the issues that might arise if 4000 clients miss 1 packet or are out of order what does your code do. And we'll see how it works day 1. Not to play puns but a quick solution to this could be implementing communications via QUIC-go which is googles UDP implementation. Again i don't know from the developers side how hard/quick (*tish*) that would be. Or I'm just an idiot and nothing matters anyway, keep up the great work prime!

he said on stream that udp takes too long to code and he wants the game to be up soon and tcp is just easier

he literally says why at 1 minute into the video 🤦‍♂

​@@JustSomeAussie1 it was a joke

@@darouigougoui2969 it was a joke

@@JoshuaMoreno yeah I thought so, but I wanted to leave my comment just in case

quic is very difficult to implement and remember (which i didn't explain well) that i have neovim as my client. which means i _just have_ tcp or udp i would have to build parts of quick into neovim via lua. no thanks

Ah yes, I did not realize you were using neovim as your client. My mistake. Integrating quic into neovim sounds nightmareish. Quic is UDP based at least 😄