
In fact, I think they're one of the most important ideas in computer science.
The problem is that they work so well that people stop asking what's underneath them. ← THIS. THIS RIGHT HERE.
I have the opposite problem.
I refuse to use an abstraction until I understand what it's abstracting away. every. single. time.
I write when something doesn't make sense and then suddenly does.That includes: abstractions that annoyed me, things I rebuilt from scratch, f irst principles I had to find myself. Just me thinking out loud, cleaned up a little.
"If I was responsible for something real, I needed to understand it completely."
Frontend was fun until it wasn't. Then my friends pulled me into a venture. Handle the backend and infra. I said yes. Then the paranoia hit. Not "I know how to deploy things" understand. I mean, open Wireshark, see an RST packet, and know immediately why the connection terminated. That kind of understanding. So I started at the beginning with Beej's guide. One thing stuck: sockets are endpoints. Bytes go in, bytes come out. That was enough to keep going.
that's where your process touches the network →"I needed to know what a protocol actually was, from the byte up."
Everyone said learn a language by building something real. So I opened the Go docs and immediately noticed, all the syscalls, the bind, the listen, all of it was gone. One line and you have a listening socket. And then it hit me. If Go is abstracting all of that away, and all a protocol really is is bytes sent and meaningfully parsed... I could just make my own. So instead of building an HTTP server, I built CSFTP — my own file transfer protocol. Not because FTP needed reimplementing. Because I needed to understand what a protocol actually was.
not terrible. educational. okay maybe a little terrible ←"I can't beat Redis broadly. So I found a specific constraint where I could win."
I wanted it faster. Faster meant C. CSFTP had disk IO so I wanted a pure networking problem: a KV store. Which is basically Redis. I obviously can't beat Redis broadly. So I found a specific constraint: 64 byte entries, cache aligned to a single cache line, 1 million key static hash table. Deterministic performance. For that specific payload, VegoshDB aims to beat Redis. That's not a limitation. That's the design.
cache lines are beautiful actually →"Well.... that was a side quest!"
VegoshDB was built around a specific hashmap design: 64 byte slots, 16 byte keys, 32 byte values, robin hood probing, prefetching. This hashmap was me venturing into the rabbit hole of memory. Built it in Rust, Zig, and C++ Now I'm benchmarking it against hashbrown and ABSL.
the engine powering everything ←"Why stop at TCP?"
After progressing quite a bit on my TCP implementation over a TUN interface, I realised, why not do more? So, I decided to implement, ICMP, UDP and TCP over a TAP interface. Implementing my own ARP, ping from absolute scratch. As close as to a NIC I could get with minimal abstractions
whaaaaaaaaaaaaaaaat →"Wait, why usize?"
While exploring zig, I saw zig's library returning a usize for syscalls. The question why usize led me into deep dive into x86 architecture, understanding syscalls down to the CPU instruction and I came out of the rabbit hole with a minimal type safe wrapper over x86 syscalls.
One heck of a rabbit hole ←"nc doesn't do a proper 4 way teardown. that bothered me enough to rewrite it."
I was using nc to test my TCP implementation. Quit the process and my impl got stuck in the last ACK state. So I wrote miniNC with a terminate command that completes the handshake correctly. Then I thought, why stop there? Why not send packets at completely wrong states? SYN during ESTABLISHED. RST when the connection is half open. See if the implementation actually holds. So I added chaos mode. Because WHY NOT.
hehe →"Kernel's where slow, but I wanted to FEEL why."
MUDP or My UDP. I wanted to know how kernels implemented networking, because you can't bypass something you truly don't understand My own UDP implementation which is a kernel module and can be called via socket().
One step closer to the final boss ←"Understanding TCP wasn't enough."
TCP from scratch got me far. But I needed to understand everything the kernel does silently before a single byte reaches your application. So I am writing virtual NIC driver in QEMU. Now epoll and io_uring aren't fast paths I'm blindly following. They're things I actually understand from underneath.
layers all the way down ←"The original goal. Still the horizon."
This was always where it was heading. Kernel bypass networking. The point where the abstraction doesn't just get thin — it disappears entirely. I spent six chapters making sure I actually understand what I'm bypassing. That's the whole point.
story isn't over →Opened for Salim–Sulaiman, Javed Ali & KR$NA in front of 8000+ people. MIT Manipal.
opening. for that lineup. →Beat 20+ bands at one of India's largest student-run cultural fests.
then opened the pro-show night. same festival. ←One of India's largest semi-professional band competitions. Waves, BITS Goa.
semi-pro. we were students. →
Intercollegiate cultural fest of KMC Manipal, MAHE.
Took home ₹50,000.
won. went home. →I'm a Carnatic flautistIndian classical music from southern India. University threw me into collabs, which slowly became fusion work. Carnatic music getting mixed with metal, prog rock, jazz and basically everything that probably shouldn't work together. It does anyway.