thanks for the demonstration! Aside from direct managing socks via syscalls, there's also an option to give it away to a separate tool like nc or tcpsvd with that kind of approach, only routing logic will be required, so, even smaller amount of lines will be involved
Truu, but the goal of the video was not to use external deps. Netcat is an external dependency. Looks like tcpsvd is a busybox resource, so maybe the challenge still holds, since tcpsvd ships with your system and you just need to configure it at build time
I was at around 5:14 when I realized the title didn't specify a particular libc for a particular OS, and then realized it's clarified in the video description. might be portable to pull in bioniclibc or some other ndk for other OSes / libc, but at that point I'd be working with a different target. still a cool demo project though.
Yeah, but the idea that MacOS SDK includes libc by default. So if you build this thing on macOS you don't really need anything the libc comes with a system, gots dynamically linked and you don't need anything except the built-in assembler and linker
If you'd like a PR into the repoi with your version for x86 we can create a repository of HTTP server implementation in all the platform's assemblies. OHHHH I LOVE THIS IDEA
You could strip down all the socket stuff if you just make it run in initd style. Basically, someone else runs a listen-accept loop, and on each accept they spawn your server and give you an fd number to read from and write to. Since you already use 'read' and 'write' instead of proper 'recv' and 'send', there is no change needed. You can even make it read command line and set to what fd you want to write and from which fd you want to read, or set both to the same number. That way you can make it truly inetd-style, without any networking needed.
The real hard part about HTTP requests is that you can overread lines, so you have to manage your buffer. It's not that hard, basically just a pointer to the actual memory and 2 offsets, to the start of unread data and to the end (size can be just a literal constant, there is no real point to reallocate buffer). The real issue is to come-up with a good enough API for you to use in all the contexts where you consume data from a buffer and suddenly you need to read more. You'll need to handle cases when there is no data on the socket/pipe left (client hangup); when buffer is fully filled-up and you need to propagate that state to the caller somehow (because you may want to do different things with that information in different context instead of just calling 'exit' or just returning '0' and make the caller to basically process all the possible reasons why that happened); make a method for a caller to distinguish between states when memory was full and when client returned not enough data, but still did not hangup.
Great video! I am not a big ARM user or writer so I Might try doing something similar is x86 although I doubt I can do it in even 300 lines. 1 question: What is that addon/plugin for your nvim which shown the cursor jump between pages?
All the syscalls will be the same but everything else just be different. I think to create an implementation in all assemblies and keep it in the main repo for fun. If you have some time and curiosity PRs are welcome for translating this thing in x86
That is awesome dude! It reminds me of the people who put games into a 512 byte sector. How much ram does it use for that tab? It blows my mind how bloated some websites are these days!
You're just a chill guy that write a real HTTP server in ARM assembly
thanks for the demonstration! Aside from direct managing socks via syscalls, there's also an option to give it away to a separate tool like nc or tcpsvd
with that kind of approach, only routing logic will be required, so, even smaller amount of lines will be involved
Truu, but the goal of the video was not to use external deps. Netcat is an external dependency. Looks like tcpsvd is a busybox resource, so maybe the challenge still holds, since tcpsvd ships with your system and you just need to configure it at build time
Dude you're awesome. Just came by your channel and I rarely comment a youtube video, hey maybe a first! Good job here! Keep it going :)
I was at around 5:14 when I realized the title didn't specify a particular libc for a particular OS, and then realized it's clarified in the video description. might be portable to pull in bioniclibc or some other ndk for other OSes / libc, but at that point I'd be working with a different target. still a cool demo project though.
Yeah, but the idea that MacOS SDK includes libc by default. So if you build this thing on macOS you don't really need anything the libc comes with a system, gots dynamically linked and you don't need anything except the built-in assembler and linker
very cool video, great to see .
Is there any practical use? and interesting benchmarking results?
What are the security shortfalls?
Great work
Im more of am x64 asm guy but this is based, gonna try to translate this to x64 asm just for the kick of it
If you'd like a PR into the repoi with your version for x86 we can create a repository of HTTP server implementation in all the platform's assemblies. OHHHH I LOVE THIS IDEA
Also make one in PDP-11 assembly pls
Okay waiting for your implementation of React in assembly lol
You could strip down all the socket stuff if you just make it run in initd style. Basically, someone else runs a listen-accept loop, and on each accept they spawn your server and give you an fd number to read from and write to. Since you already use 'read' and 'write' instead of proper 'recv' and 'send', there is no change needed. You can even make it read command line and set to what fd you want to write and from which fd you want to read, or set both to the same number. That way you can make it truly inetd-style, without any networking needed.
The real hard part about HTTP requests is that you can overread lines, so you have to manage your buffer. It's not that hard, basically just a pointer to the actual memory and 2 offsets, to the start of unread data and to the end (size can be just a literal constant, there is no real point to reallocate buffer). The real issue is to come-up with a good enough API for you to use in all the contexts where you consume data from a buffer and suddenly you need to read more. You'll need to handle cases when there is no data on the socket/pipe left (client hangup); when buffer is fully filled-up and you need to propagate that state to the caller somehow (because you may want to do different things with that information in different context instead of just calling 'exit' or just returning '0' and make the caller to basically process all the possible reasons why that happened); make a method for a caller to distinguish between states when memory was full and when client returned not enough data, but still did not hangup.
Great video! I am not a big ARM user or writer so I Might try doing something similar is x86 although I doubt I can do it in even 300 lines.
1 question: What is that addon/plugin for your nvim which shown the cursor jump between pages?
ok, now i will try to write one for x64.
not watching the video until i complete that.
A very clean demonstration. How it would translate to x86? I would love to do the same with fasm.
All the syscalls will be the same but everything else just be different. I think to create an implementation in all assemblies and keep it in the main repo for fun.
If you have some time and curiosity PRs are welcome for translating this thing in x86
Thanks 🙏
Great vid dude
That is awesome dude! It reminds me of the people who put games into a 512 byte sector.
How much ram does it use for that tab? It blows my mind how bloated some websites are these days!
Could you also write an http client same way, please?
Damn ,subbed
nice!
nice
server*
wait, 200 lines?
did you cheat with macros or by using libc?
watch the video..?
@@khuntasaurus88 ( read the comment that is immediately next to this one )