I Wrote HTTP "From Scratch" (It Was Easy) 

If anybody is determined to bless the world with this, I'll help where I can!

Same here 😂 This is still cool.

@@shinej11 Python's is imo the least evil scripting language, and can do some low level stuff too. I once implemented some serial networking protocols in Python on a microcontroller. Use the right tool for the job and have fun!

Oh for sure. You take your UART data, format it into a buffer and you can make it available over TCP with HTTP just like I've done here. Doesn't even need to be HTTP/webserver! Only if you want to load it in a web browser! It's probably easier to have the ESP32 be a TCP client that connects to the PC acting as a TCP server (HTTP or not). UDP is likely to be even simpler, depending on your needs. I've done a lot of Arduino programming, it'll likely have libraries to make all this easy enough!

I literally googled HTTP RFC and immediately started writing the code. I was roughly today years old when I saw there was http 2 and 3 so I don't know yet 👉👈 I've heard they're the same protocol, but with a binary format and extra features, so it should be doable!

That's abstracted away by the library such that it's simple. The operating system is involved in the protocol, such that the library that implements the protocol, interfaces the operating system for various utilities to assist it in doing so. Encryption algorithm: library code Reading a certificate file: OS code So yeah its more than likely that it (openssl code) encrypts the data before just sending it over send().

​@@seanbix5366 Thank u for clarifying this. Good luck with what ever u are doing today or u are planing to do tomorrow 🙃.

Yes, and yes. This is "socket" programming, the operating system's abstraction of TCP/IP which you can do in C#. That's how you would send the HTTP header string and data. This is purely for learning purposes though, it's not massively practical or idiomatic. C# has easy HTTP interfaces. The project is linked in the description!

@@grenadier4702 All of my sockets are "non blocking", but they block anyways (lmao) because each connection is accepted in its own thread. TCP multicasts make full use of non blocking IO on one thread through. All file reads are lazy loaded and cached into memory with mmap so its eh, good enough on that front I guess. Not a hash map or event queue in sight, just a simpleton, liberally mutex locking.

​@@seanbix5366 Yeah, I see now. Here, right? while (er == RECV_TRYAGAIN) { er = tryAcceptConnection (localhost, remotehost); } You're basically looping until an error or a connection arrival? And here in each thread you just check for blocking and repeat the same loop again? else { if (errno == EAGAIN || errno == EWOULDBLOCK) { continue; } fprintf(stderr, " Socket error, closing connection... "); closeConnections(args->remotehost); } But why do you need non-blocking sockets here at all? When you accept a connection, if it would block, you repeat the same loop again so it's the same as a blocking socket. In second code block, it;'s the same thing: even if it's non-blocking, you do the same loop, i.e. waiting for data arrival, blocking other tasks in your thread pool Maybe I misunderstood your code? UPD: fuck, i realised you wrote "but they block anyways", sorry :) But the question is why did you use non-blocking sockets at all, then?

@@seanbix5366 oh gosh, freaking youtube deleting comments I checked out your code.Why did you use non-blocking sockets in the first place? Because I see even if errno is EWOULDBLOCK, you still iterate over and over waiting for data to arrive or send

@@bladekiller2766 Oh for sure. Dead simple, its in the title. If you want to actually be productive, you can always grab a library/framework for whatever. But now I don't have the third party dependencies, and I learned the protocol inside and out! From my experience- there's always an underestimated leap from thinking you understand a technology, to actually being able to implement it which can be fun to discover. Plus this is targeted more towards IT people, who often overestimate a lot of complexity in the tech they're using.

@@seanbix5366 Couldn't agree more. All the tech stacks and networking complexity looks extremely complex, but when you try to implement it from scratch by yourself you will suddenly realize that it's doable and it will give you insights on why some things are the way they are. Props for doing it in C :)

@@singhyuvraj122 I won't be doing any TCP/IP implementation until I end up working more in embedded and need to make one. An email server sounds rad though!

​@@seanbix5366i think sockets allow you to send raw link-layer packets (ethernet frames) so you can probably implement TCP/IP from userspace

@@xorxpert Nice! I have a websocket deepdive on this channel too- the variable length length encoding and payload masking were wicked, but worth it in the end!

@@seanbix5366 It was mostly challenging for me at the time. I usually like to learn how things work for experience but mostly avoiding third party or standard libraries. Whilst working on a multiplayer game, I built my own websocket server & client in the process along with a protocol library, for handling sending packets efficiently properly writing/reading and parsing data (binary), while converting between respectable objects. latency was very important, all unmanaged code. Performance, speed, and efficiency was the focus. Per protocol standard for large payloads, you have to deal with splitting the data into frames, and you know TCP, you got to handle waiting and acknowledging packets - multi (safe) threaded 😅 Took me about a mouth until i was entirely finished it, though was fun and worth learning!

@@xorxpert So far none of my websocket payloads are larger than a few dozen bytes... But I was under the impression that I could simply cram an arbitrary amount of data after a websocket header and TCP would eat it? I don't remember, need to look at the code! I fetch all the BIG data with http from JS anyways.... Good work! I couldn't even find a simple websocket library anyways.

Fair. I suspected the overlap between between people who don't know HTTP and how the TCP/IP stack works was near 1:1, and targeted that audience. The implementation itself is not impressive (it's in the title) but it seems to have served it's purpose in giving lots of people a deeper intuition for the entire system (and powering my webserver)! I'm sure we can agree that conventional explanations (like wrapping a parcel) fall short.

I'm sorry to hear that

I have a soup recipe that'll fix you right up if you wanna hear it!

You forgot this isn't Reddit

@@swojnowski453 I just want a cool video game for my friends and I, and to learn these technologies along the way. I'm building on top of it, I care, and its pretty chill!

Well, what would you like to know my guy?

@@seanbix5366 When I made chicken pot pie, the filling was fine but the puff pastry on top didn't puff up though it did cook through. How can I remedy this? The pastry was the store-bought frozen variety. The temperature was 375 °C and I used and egg wash for the glaze.

@@owenbrown9694 1. Thawing - Avoid an IP Collision Proper Thawing: Make sure your puff pastry isn't experiencing an IP (Instantly Pulled) collision by giving it time to thaw in the refrigerator, ensuring no network (temperature) congestion. 2. Temperature - Keep Your Layer 4 Connections Strong Correct Heat: Your oven needs to be set to 375 °F (190 °C). Think of it as keeping your TCP (Thermally Controlled Puff) connections strong. Too hot or too cold and you'll have trouble establishing that reliable connection for puffing! 3. Baking Setup - Packet Delivery Preheated Dish: Preheat your baking dish to prevent any packet loss, ensuring a more reliable delivery of puffiness. And remember, the filling should be hot, so the top layer gets a good handshake with the crust. 4. Egg Wash - Smooth Communication Application: Apply your egg wash gently, just like a smooth handshake protocol, to establish a golden connection without network (pastry) congestion. 5. Pastry Handling - Avoid Fragmentation Thickness: Roll out the puff pastry to about 1/4 inch, keeping it uniform to avoid data fragmentation in the layers, ensuring all packets (layers) arrive intact and puffed. 6. Pastry Resting - Time for ARP Resolution Cooling: Let your pastry rest for a bit in the fridge after rolling it out, allowing the Address Resolution Protocol (puff pastry layers) to map the correct layer addresses (butter) before baking. 7. Avoid Overhandling - Prevent DDoS (Dough Denial of Service) Minimal Handling: Don’t overhandle the dough or you’ll experience a DDoS attack on your puff pastry’s ability to rise! 8. Ventilation - Manage Network Traffic Steam Release: Make small slits in the pastry to manage network traffic (steam), ensuring no data packets (steam) get lost, causing network (pastry) puff loss. 9. Cover the Edges - Implement Firewall Rules Edge Protection: If the edges are browning too fast, cover them with foil as a firewall rule, letting the rest of the network (pastry) puff up securely without packet loss (burning). Troubleshooting Tips - Ping Your Pastry Temperature Checks: Make sure the oven temperature is accurate, much like pinging to check network latency. Proper Layering: Ensure the pastry's layers aren’t merging like a VLAN (Virtual Layers Absent Network). Steam Release: Remember, too much trapped steam can cause a denial of service on your puff pastry’s puffing ability! Summary Thaw properly: In the refrigerator, avoiding an IP collision. Correct temperature: 375-400 °F (190-200 °C) for solid TCP connections. Preheated dish: Ensures no packet loss. Gentle egg wash: For smooth handshake protocol. Minimal handling: Prevents DDoS on dough. Steam vents: Manage network traffic effectively. Edge protection: Implement firewall rules with foil. Let these tips serve as your protocol stack for perfect puff pastry puffing!

@@seanbix5366 Thanks but could you give the instructions for a 300w microwave oven? Its all I got.

@@owenbrown9694 Ah, you got me. The only thing I'll never open source.