On this page On this page
episode 18 — Curiosity, Quake, and Networking with Fabien Sanglard.
Glen talks with Fabien Sanglard about curiosity driven engineering, from early computers and classic games like Doom and Quake to modern Android development and ADB. They discuss how networking evolved in games, why latency shaped multiplayer design, how Rust improves reliability in large systems, and why writing and diagrams are powerful tools for truly understanding complex technologies.
If you like this podcast you might also like our modular network framework in Rust: https://ramaproxy.org
00:00 Intro01:19 Fabien's background07:02 Android Debug Bridge (ADB)11:05 Fabien's Blog16:45 mDNS and Blog Target Audience24:23 Quake TCP/IP32:37 Nostalgia with Pink Glasses37:58 Later Quake Versions39:58 Fabien's books41:53 The importance of Diagrams in documentation47:19 Lessons that can be learned from ADB51:58 Rust Iteration Speed59:22 Outro
Music for this episode was composed by Dj Mailbox. Listen to his music at https://on.soundcloud.com/4MRyPSNj8FZoVGpytj
Elizabeth (Plabayo)
0:12 | 🔗
This is netstack.fm, your weekly podcast about networking, Rust and everything in between. You are listening to episode 18, recorded on December 12th, 2025, where Glen has a conversation with Fabien Sanglard about Quake, TCP IP and Fabian's decades-long journey exploring how early computer systems really work. from operating systems to hardware and protocols. Welcome for another week of Netstack.FM This week I'm very excited because my guest of this week is Fabien (or Fab) He is what I call a software historian even though he also covers hardware. It's not his day job but I've personally been following him since like close to two decades on his path to explore and write about how different software and hardware or even the combination of them work. So welcome, Fab (his preference to shorten Fabien) Hello Glen thank you for having me. Yeah, thank you for making some time. So as is the tradition by now in our wonderful podcast, I think it's nice if you first could introduce yourself a bit like where you come from and how you came to the job that you're right now at Google. As far as I can remember, I was always very curious about the world around me. And I always love, for example, biology to understand how life works. Civil engineering was also very interesting to me. Understanding how electricity was generated, how water was processed, all that stuff that makes things magical, like you switch a... a you flip a switch in a room and then you have light coming in. And of course that applied to computer. What I really like about computers is that it's not just something you can turn on and off. It's also something you can program. So you can put some of your mind in it and then it behaves according to what you decided. And I discovered that at a pretty young age, I think I was seven when I wrote my first loop and it was logo. And in logo, you have a turtle that you can put down on a sheet of paper and then repeat 360, advance one, put it down, move one, lift it and then go back to the center and stuff like that. that's, we had computers at school and it was a program initiated by a French politician and the program was a computer for everybody. So they brought computers and those were Thompson MO5 8-bit computers. And they were all networked together. And that was really, really cool. Like we had the optical pen to play with. And from that day, I think I was hooked. We had weekly sessions. And I remember distinctly signing up for going after school. So usually I was very eager to leave school and go play soccer. But for computers, I would stay after. I think I easily clocked like three hours of programming when I was seven. And after that, it was just a process that was started because I started to ask for computers. So I got a Spectrum, a Sinclair Spectrum at home, and then I installed CPC, Atari, and then I moved into PCs. And we almost never had a video console at home. we always had a computer. So I was really used to thinkering, going deep, trying to understand how things were working. And that's how I ended up with a master of science in computer science. I moved to Canada shortly after I graduated because I wanted to discover the world. And I thought I was going to stay there forever until I got a job offer from my dream company. which was Google. And that's how I moved to USA and eventually became a US citizen. And I'm still employed at Google. And I love it there. I don't see myself ever moving. I work on Android. It's been 11 years. And yeah, that's my introduction. Very nice. As you work on Android, does it also mean that you evolved in the Rust adoption or that you now also have Rust as part of your job or I don't know like how segmented these teams are. yes. I was very eager to jump on Rust. I am the owner of a program called ADB, which is ⁓ the debugger bridge, Android debugger bridge. It has a long history. It started in C and it moved to C++. It had many owners before I adopted it, essentially. It's a complex... codebase with many streams, a lot of things happening. There is multi-threading, are mutex everywhere. And ⁓ that's the ideal codebase to evolve to move to Rust. So part of what I do in my job is I'm rewriting some module in Rust. And any new module, we try to write them in Rust. And the latest project we are working on right now is we're trying to improve ADB Wi-Fi. to make it more reliable. And Rust is instrumental ⁓ because you can only run after heap corruption and buffer overflow so many times in your life before you decide that. There is a problem with C++ at its core. And if C++ is used right with people who know the language and they love their product and they treat it like almost like their baby and they take care of it and they try to think in terms of architecture when they had a new feature instead of jamming it in. It can work. C++ can work, yes. But if you want to be 100 % sure that you're never going to have a problem and if you don't have the ideal condition I just described, is definitely the way to go. We've been doing that for a good six months now. I'm so happy with my decision and hopefully I'm not going to have to write C++ ever again. Amazing. I didn't even know you were the owner of ADB. Like I've used that tools for so, so many times. I mean, I guess a lot of us, every time you have to touch Android, I mean, it's a wonderful tool. And I imagine it's probably like quite a big project because it touches like everything. Yeah, it's hard to make changes because the slightest, most obscure detail or even undocumented behavior is relied upon. We have like millions of millions of developers. And I remember just fixing a bug where we had a command that did not constantly return an error code. And somebody was like, I'm just going to fix that. ⁓ Put zero when it succeeds and one when it fails. And just fixing that actually broke people because as they wrote their test a certain way and they were relying on having unreliable error code returned. So, yes, it is a hard project to maintain. It's challenging. That being said, it's used for everything. So you can really make a difference. I remember, for example, ⁓ improving performance by 20 percent. And I did the math on how much electricity in times was being saved, power, ⁓ and even just money. It was huge when you add up. So slightest thing ⁓ matters in both ways. You can create a lot of problems for people if you're not used to that kind of product, but you can also greatly improve the quality of life. And that's what I like the most and that's what we've been doing with ADB Wi-Fi. and talking about ADB and the wifi, how does the network stack look like? Is it just piggybacking on the one of Android or does it bring its own tools and own protocols implementations? No, so the person who wrote it originally, ⁓ Sweatland, ⁓ really did not like to have dependencies and he really liked to write everything. So no, it's just using TCP and USB. There are no dependencies. And it's doing all of the multiplexing ⁓ manually. So nowadays, if you work with USB, you have something called Stream. to multiplex a little bit like the way TCP does. But you cannot do that. On USB, you could not do that back in the day with B. So that is done manually with something called the A protocol. I'm not going to jump into too much details, yeah, that's pretty much, everything is done pretty much in-house on ADB. Yeah, I mean, then again, you said it was originally... Was it originally in C++ or what was the original language? Okay. Originally it was written in C and then the codebase evolved to C++ and now it's evolving to Rust. because yeah, I mentioned because yeah, both in C and C++ and that's also what I'm used to is, I mean, it's not that abnormal to just write everything yourself, right? It's pretty rare, but I think on ADB we've been beat quite often by using a dependency or something and then the level of support changes or we need to make change to that are not compatible with the way the people want to see the code base go. And then you're stuck and you have to fork the project and you're in a worse place than you would have been if you had just written your own stuff. because then you have all that framework ⁓ that does a lot of things that you don't need, plus your stuff. So ⁓ that's why things are done this way. Okay. And then so like I said, I've been following your blog since quite a while. At times you were very active at times not, but I mean, I'm subscribed to so I can see them coming in. Like how, yeah. There was a three year gap, yes, in my updates. It's when I was trying to write my first book and I gave up two or three times. I forgot how many times I gave up, but yeah, all of my time was spent trying to make the book happen. Okay, I mean that's a valid excuse and not that you need any excuses like it's anyway, it should be fun, right? It's a block so not something, it's not a second job I would think so. As I often say, it's not excuse, there are no excuses, but it's a reason, it's an explanation. Very good one. I'm getting a lot of knowledge already from you. So how do you pick these topics? Do they just like, I don't know, for example, recently you wrote like a lot of, not recently, but like this year, I saw a lot of blog articles from you about the IBM machine. Like, is it because you bought one or? No, no, no, it was the other way around. So the way I go is that I just follow my curiosity. I mentioned earlier that I was always very curious, which is good in a way, but it also couldn't be a curse if you don't keep yourself focused. So usually when I pick something and I find to start to be interested in something, that's why I write this article, because that's the way for me to have a closure. And as If I don't write something about it, I don't allow myself to move on to the next topic. It doesn't always work, but it mostly does. And that's the way I found that I'm able to move forward and make things work. Otherwise, I just disperse myself. And the way it works for the case of the IBM, it was just ⁓ a childhood memory of my first PC being severely underpowered. I was playing Doom at 10 frames per second. And the neighbor had that beautiful IBM, which was running Doom flawlessly at at least 20 frames per second, which back then was a very high number. And I was like, I've always wanted this machine and I always wanted to explore what it could do. And I just went on eBay and I started to find if they were available, I started to do some research and I eventually got one. It's a box I wanted to check. But on a more general term, think I'm always driven by curiosity, which is itself finds its roots in passion. I think if you're passionate about something, you're more likely to eventually to keep working on it and kind of complete your small project. ⁓ That's how things happen with me, curiosity and passion. If I force myself to work on something, it can be good, but usually I find that it's not as good as it could have been. Okay, and do the, I mean the fact that you make a blog post around it, it always like on purpose or is more like in general you're curious, you're discovering things and at some point you have sufficient notes or you think like, okay, there is more here and only at that point you start to maybe think about an article. So the article is usually for me a way to complete a topic I was working on. And it's a way for me to verify that I've actually done what I intended to do. I found that very often when you try to explain something to someone, if you don't really master it, ⁓ the crack are going to be very visible. So writing something at the end of a project is for me a way to check that. ⁓ My knowledge is sound and I've actually ⁓ investigated everything I wanted to look into. And quite often while I start writing an article, I'm like, I have this idea and that actually very interesting. So I go back to the project and I work some more on it. it's, ⁓ it's a, it's a way for me to check that I understand and I master my topic. It's also a way for me to kind of not waste my time because I'm like, a lot of people investigate super interesting things and they never write about it. And I've made people like that very often, people super knowledgeable, you go on a forum and they know everything about a video game or about a game console and then they don't write about it. This knowledge is there, but it's not available. So I always kind of think of somebody who may be interested in this topic. I quite often mention that I write the book that I wish I could have just have bought, like the Game Engine Black book about Doom and more French thing. I'm quite lazy. I just wish I could have bought this thing because I was interested in it. And there are many books that I write and people have done exactly what I do. They were very interested in the topics they wrote about it and I just can spend the money and... They saved me all that time by sharing their knowledge. So it's kind of way for me to return the favor in a way. Yeah, very cool. so, like example, a blog post I liked from you a couple of years ago was the one about mDNS, where you kind of like wrote like a little mDNS primer and you're linked to a YouTube talk there, I think about Bonjour, if I remember correctly. And I think you even mentioned, I mean, what I found most surprising is also that the fact that you at that point mentioned the Unix network programming, which is quite a... like a piece of work like to to get through it and to to read it ⁓ if you look back at the the blog post like that like do you still like that kind of like article or how you feel about which articles after some years So that's a very interesting question. The further back in time I go back and read the stuff I wrote, the more I cringe. Which in a way is a good thing because it means that my English and my skills in a way is improving. But the very early articles, I'm kind of embarrassed of them. I keep them online just because I think somebody may find them interesting. But the English is like it's riddled with errors. It's not very deep. Like the type setting is embarrassing. So some of those, yeah, I have, it's a bit of sweet feeling to read them. All the ones I wrote, think after I wrote the books, I think I really started to really put a lot of effort into presentation. ⁓ also my English improved quite a lot over the years. So the one you mentioned about mDNS, I'm very proud of them. All the ones I wrote after I changed the layout, you know, with the monospace font, they are pretty solid. And I kind of plan on writing more about mDNS, by the way. mDNS is a core technology used in ADB Wi-Fi. And that's why I wrote about it. And so more of those will come if you enjoy mDNS. But yeah. I mean, I enjoy anything about networking basically. I can consume these. I mean, there's always... I like it especially because... To me, even though I originally come from the game industry, ever since I discovered network protocols and how they're implemented, I feel they combine so many things together. They combine low-level protocol implementations. They combine even the fact that there is a reality, there is a world there, so have to deal with that, which causes latency in all kinds of ways. There is the fact that you connect different machines together that now need to correspond with each other. like the matter of security like it's yeah I mean like it's to me it's like a little bag of candies because it combines everything basically. So I would say that you are the ideal reader for that kind of article, but when I write, I always kind of give myself the challenge of... ⁓ How can I say that? You've probably had... Everybody has had a teacher at school where like, I did not like this topic, but that guy was so good, I loved it. And I have vivid memories of a... teacher who was teaching history. before that I was never super into history, but that person always came up with anecdotes and a way to present things that was interactive. And, and I became passionate about history thanks to this guy. So when I write article, I, kind of always give myself this challenge to like, try to make it interesting. And if I can make people who are not like you, who are not interested in networks. And if I can make them like mDNS or be interested in mDNS, that's really when I think it's a big win. And it is challenging with network protocol because they are not very well documented usually. You have like RFC somewhere. And if you're lucky, somebody wrote a book about it, like in the case of mDNS. But there are many, many, many topics around which... I would like to work on and just not dumb them down, but just make them more attractive to people and be like, you know, it can be fun to read about. Yeah, that's a very good challenge. Anyway, it will make search articles better for everybody, as you mentioned. Now... ⁓ You also wrote a bit on the SNES, like it's also a very interesting topic. Not so much we're going to discuss today, but what I do, kind of not sure if I missed that, but I found it very interesting how back in those days, the cartridges, I mean, they weren't just storage devices. weren't just storing your game, your assets. They were also often bringing their own hardware, like to bring capabilities that the machine, be it like a console or a handheld device didn't have. and I found that quite magical because as a child you let's say you have some kind of gameboy or you have some kind of console and suddenly it can do a lot more and it's basically because they bring their own hardware in in those cartridges Yes, it did feel magical as a child to play the Super Nintendo. what's remarkable is that even when you lift the hood and you start to learn how it works, to me it becomes even more magical because I understand the constraints they were under and they still managed to make some of the best games of all time. And it was really vivid to me when I started to study the video system. I'm not going to into too much detail, but you have seven modes for the SuperNAS, for the video, for the graphic rendering. And every single one of them is pretty much pushing the hardware to its limit. Everything was based on ⁓ RAM latency, because you need to output a color ⁓ for every line, for every single pixel. So they could, ⁓ like the CRT never waited. You could not just write a frame buffer and then transfer it when you were done. You were just issuing a pixel as they were needed. And to me that's what even more mind blowing. And that's also an inspiration for what I work on every day. It's always the same story. It's always been the same story ⁓ of people inventing things. You are under... You have limited capacity in terms of like processing speed or storage. And it used to be true when you were programming a web server back in the nineties or even nowadays when you work on an NLM. We routinely mentioned billions of parameters, but they are limited and they need to do the most, the best they can with what they have. And that's what I get a lot from looking at those old machines that the mindset is still the same. You push. you push as hard as you can with what you have in order to reach a goal. Yeah, that's for sure. And I hope we keep pushing, although not forget to be kind to each other. yeah, that said, like I enjoyed it a lot and... And the reason why I wanted to invite you mostly is also around your Quake article where you mentioned a bit of the history, like how did it get its TCP IP stack? And it's mainly, I think, around the more modern version, not the super modern version, but on Windows 95 and beyond. But you do start the article talking a bit about how it was on DOS. And as far as I remember, in a system like DOS and the ones before, like systems had to bring kind of like their own network stack. But I wonder, like, developers write it each time from scratch? did every company have their own implementation or were there some like library vendors and you could kind of like license their code from that? So in the early days you could just buy a network card and you could set up a network on top of something called IPX. And for IPX network you did have ⁓ stacks that came with the network card. So you had a driver for that. So it worked. It worked really well. But you were limited to a local area network. As soon as you wanted to go on the internet You need to have a TCP IP stack, which is way more complex. And back in the day, you had to buy one, which was almost a thousand dollar. It was extremely expensive. from what I read of the little open source, the little source code we have about games of those era, usually people were just going with EPX. It's only As far as I know, with Quake, they made this really convoluted bridge to be able to access Winsock under Windows 95 that people really were able to play on internet. But even then, it wasn't perfect. mean, the thing that is really telling by how early they were is that John Carmack had to write Quake World because he found out that as soon as you had more than 300 milliseconds of ping, his architecture would not work anymore. had to ⁓ introduce prediction on client side. had to allow the player to move before it was acknowledged by the server. I think developers never wrote TCP stack. It's just too complicated to answer your question. And we've quite used the one from Windows 95. Hmm. Okay, that makes sense because I mean, I don't remember any multiplayer game that I played like multiplayer as an internet game on those systems like the first internet connected games I played was already on something like Windows 95. So that makes sense. I I guess they must have existed but yeah, not come to my mind. So what you did for example with Doom is that you had companies who would specialize in forwarding connections. So Duango for example did that. You could run the program, was a TSR, that would forward the Doom packet to their server and then they would let you play with people which were not on your LAN. It was kind of internet before time. The architecture of Doom was very different from the network ⁓ architecture of Quake. When you play in a network in Doom, for example, every single machine is running their own simulation. They can only render the next frame once they have received the command for every player. So even if you had a pen, you're able to run at 35 frames per second. If you were playing with somebody who had a 386, and was running at 10 frames per second, your frame rate would drop back, drop down to 10. Because your machine could only render a frame once it had received the command from all the machines, including the very slow 386. Quake moved to a very different architecture where you had a central server and all the clients were being updated asynchronously. that worked better. And that was the first version they had where... they had a dumb client which would just send commands and only do something when the server acknowledged those commands. And that worked well for the testing because I think John Carmack was on a T1 line with very low latency. But as soon as they put it in the open net, that system didn't work very well. Especially when you were moving around. So you could look around and that did not require the server to acknowledge anything. But ⁓ as soon as you wanted to move, that had to be acknowledged. And as soon as you go past 300 milliseconds, it starts to show and it's very noticeable. So they solved that with quick word-wear. They were predicting and allowing ⁓ local command to be acknowledged. ⁓ temporarily until they were validated by the server later on. very cool and then As you mentioned yourself, like for Quake on Windows 95, they did build a bridge. We can talk a bit about what that bridge does, but I wonder why they needed the bridge altogether because I thought that starting from those kind of operating systems, the OS was first of all already in control. Even if you start an application, it was still running on top of the OS. And on top of it, I thought it came already with like a pretty ⁓ complete network stack, no? Yes, so Windows 95 had a TCP IP stack. But when you start a DOS application in Windows, it puts it in a virtual machine. So it's called a DOS box. It's not related to DOS box, the software that was written later on. And the memory access, the interruption and the signal and the interrupt are all virtualized. It has a pretty significant impact. So I think it's... almost 25 % slower when it's running in the DOS box. And the other thing is that, yes, there is a TCP IP stack. There is a DLL that gives you functions to send packets on the internet, but you cannot load a DLL from DOS. DOS has no concept of DLL. And that's why they were using this bridge. So it's software did not write this bridge. It was a software solution provided by M-Path. And... ⁓ It was quite complicated what it did because I'm not going to go too much into details, but they had to create a virtual device that will be tied to an interrupt. And when Quake running in those virtual machine will trigger this interrupt, ⁓ it will be recognized and intercepted by the virtual device, and it will be able to access Winsock. To shorten my answer, DOS provided no network protocol. There is nothing it does. DOS is a glorified file system with a command line and able to execute bash script. Yeah, I mean, I have fond memories from it, but yeah, it was definitely different than what we nowadays call an operating system. And those memories really found, I I don't know, you know, I spent so many hours trying to get enough conventional memory and having to figure out if I needed EMS RAM or XMS memory or even loading a mouse back in the day, you had to actually load a mouse driver in your auto exit the bat. So it worked. But, and remember we did all that without internet. No internet. How do you figure out if you have a problem? There was no LLM to ask guidance. Maybe you had a friend somewhere in town you could brainstorm with. But I actually remember back in the days coming across a file with an extension I did not recognize. It was .rar, a RAR. I was like, what is that? How do, or do I use it? And then I ask a friend is like, I think it's a compression. Uh, it's a compressed archive and he had this thing called unreal, but that illustrates how difficult it was to, to get access to information and software. Like I often mentioned difficult access to information, but if you wanted to program a computer, you need the compiler and a compiler was easily, easily $2,000 back in the days. if you want to walk and see or even pass car. So it was a very different era. I don't know when, you know, I think people tend to put like roasted glasses when they look back. I'm not sure those are fond memories. Yeah, I mean, I'm sure you're right. I'm sure the truth is somewhere in the middle. Like, and I do remember indeed, back then we were still buying compilers because I received from my uncle a license for like the Borderland compiler and I was so happy now I could compile some, what was it like, I think, sequel and yeah, I don't know. But at the same time. I felt it was like all more manageable because nowadays systems are so complex and I mean we do have a lot of experience and ⁓ we always find our way but at the same time you can never feel like you always feel a bit lost I don't know like it's for everything like the commands have a thousand flags by now and there are like a million protocols and ⁓ the I don't know back in the days those let's say a CPU you could still kind of like comprehend what all the instructions were and now they are like I don't know like you need like a set of books just to get to list all the instructions that I don't know like understand them so it's it's yeah it's a lot more complex I would say I think it's a lot more complex. You also have a lot more documentation. I don't know if it's a net gain or not, because back in the days things were simpler, but we have far fewer little documentation. Like if you wanted to implement a TCP IP stack, even if you had the compiler, you need to get access to the specs. I'm pretty sure you had to pay for the specification. It was expensive. So I don't know. Which side is better? I think it's perhaps it's always the same story. You know, you have a certain amount of resources and you're trying to make something happen. And it's always the difficulty level is the same. ⁓ What is not the same, though, and I would agree with you, is that things did feel magical. ⁓ If you were playing a point and click or Monkey Island, for example, you didn't have access to an Internet page turning you the solution. ⁓ I really felt back in the days that was adventuring and discovering things, trying to make things work. It was you and the machine and maybe some obscure TXT file buried somewhere that you had to discover yourself by looking into the directory and the hierarchy. And I do have fond memory, now that we're bringing it up, solving problems on my own. And that was very valuable. Nowadays, would say quite often if you have a problem, the first reflex is going to to Google it. And yes, you solve the problem faster, but you feel a little bit less accomplished. Yeah, exactly. ⁓ yeah, I mean, yeah, anyway, I feel like I want to go on a complete side road. So I think I want to stop it early. ⁓ yeah, just to, yeah, that seems like a different kind of podcast two old guys shouting at the sky Why not give us some years that we can do that. ⁓ Maybe we can do another podcast about it. It was better before, I'm like, no, it's better now. Okay, so that's very cool, but then I guess later Quake versions, they no longer need those books because they will be made for the new system and then everything is a lot simpler, least networking wise, I guess, for them. Yeah, so in 97, it software converted their development stack to Windows NT. and they stopped developing for DOS essentially because DOS was just losing a lot of ground very fast. Within one year, think those lost 50 % of the market share and it was really all Windows NT 5, Windows NT and later Windows 2000. So everything they wrote after, after WinQuick, I think, ⁓ was all based on Win32. Quake.exe and VQuake were the last those compatible, ⁓ they ever released. And after that it was all Windows and on Windows you had, you had everything you needed. And what's really cool is that I think the code base became better and better. With Quake, when you look at the source code, can see all the things they tried to experiment on. For example, they forked WinQuake into QuakeWorld. So when they released the source code, you have actually two source code. You have two huge folders. One is WinQuake, the other is QuakeWorld. Whereas if you look at Quake2, and Quake 3, it's just one clean unified code base. And it keeps on improving. For example, if you look at the source code of Doom 3, they have a unified renderer where the models are in the world are lit exactly the same. They are affected by the same shadows and stuff like that. So it's really fun to take a trip in the hit software code base because you get better every year with every new version. imagine and then despite the fact that you like wrote a lot of interesting books like you wrote one I think around 12 and Stein 3d around doom and I think one related to arcade machines if I remember correctly Yes, the Capcom CPS-1, the machine running Street Fighter 2 and Final Fight and all those early, I would say, from Capcom. Yeah, exactly. like, despite the fact that you write also quite often about networking, so far you didn't really have any book which ⁓ dove maybe a bit in the topic around networking. I think I'm very tempted to write about mDNS. I love mDNS, it's a really cool tech. And there's only one book about it and it's kind of, it's from a long time ago. So maybe I will write about that. Yeah, very cool. And you also have, I mean, I'm not sure, we also had some episodes on our podcast around Fuchsia. And like, I guess you have a lot of people there that can probably like teach you a bit or two about networking as well. True, ⁓ However, when it comes to network, think you really need to have lot of hand-harned experience. You cannot just read the source code of something and really understand it well. ⁓ Networking is really a little bit of black magic sometimes. And also, the source code I've read ⁓ is usually not super well documented. Yeah, yeah, that's true. And it's kind of like mathematics, I guess, where, I mean, you can read as many proofs as you want, if you don't do them yourself and try to figure out solutions, you kind of just like kidding yourself that you know it. Something that really helps to understand network code is to have good example too. Like if you can have like a UML diagram or a sequence of packets, it helps a lot. And I really rarely find those in ⁓ networking code base. Okay, so maybe that's a good one because I myself I also develop and maintain a network framework called Rama and like so far we've been developing it for three years and I hope it can go for many decades onwards and ⁓ yeah the first years were mostly around many iterations trying to find the appropriate design because then the rest can be built on that. and yet the year that's coming, one of my resolutions is to rewrite the documentation and also maybe make some kind of ⁓ Yeah, let's say tutorial kind of space where they can also, there's already plenty of examples and tutorials. And I try to explain things around like what are different kind of proxy concepts and this and that. But as you mentioned, you already mentioned one thing where you say like, okay, a good diagram is good. So maybe, maybe you can give some tips around this then and this way I can apply it and try to provide better documentation for people to, because the goal of it is to really empower you, not just with the technology, but also ⁓ demystify a bit about networking and hopefully that they also learn to enjoy and the amazing things they can do with networking. So, yes, my advice, I think everybody's brain works differently. So it's really hard to appeal to everybody. ⁓ What I found though is that I've never heard anybody telling me they hate drawings. So I think it would be pretty safe to, if you were to put a lot of them in whatever you write. Like for example in mine, Like all of the books I wrote, I think I have hundreds of drawings in them because I think it works super well with me. Even when one of the articles I wrote, which is the one I get the most feedback about is when I explain how floating point works. pretty much every emails I receive mentioned a drawing instead of explaining it with a mantissa. and the exponent and stuff like that, I explain it with a window and an offset. And that's something that keeps on coming back. And I think I could almost have published an article with 50 % less text and just have kept those drawings that would have been enough. It's actually a really interesting exercise to to try to see how much you could shorten an article and still have the core of it. I forgot to say that something is finished not when there is nothing to add, but when there is nothing to remove. And it's a very interesting approach. Yeah, and do you have any tips around like how you would like draw those diagrams because I find that sometimes it's maybe too simplistic and other times maybe there is just too much on it. So my advice about that is to let it rest. So the way I proceed is that I write something and I draw something and I stop looking at it for a few days. Because if you're too close to the sheet, don't... I don't know, somehow you lose the big picture and you start to drown into details and you lose something when you're... too much into it. that's something I've done for everything I've written so far. Write it, don't publish it, leave it a few days, come back to it with a fresh mind. You would have forgotten your approach and you're going to be able to rediscover what you wrote. And almost like one of your readers. you will quite often you spot mistakes there. You're like, okay, it's not clear. I don't understand what I meant there. And I think it depends on who good or bad your memories, but I think a few days is enough for me. It may be longer for people, yeah, give yourself time. Okay, very cool. And did you ever try to make some kind of like interactive diagrams where they can see, let's even play this networking that they actually can see the networking go in its flow or did you so far stick to like static diagrams? I have a preference for static. I did do interesting interactive things. So the Doom 3 article, for example, you can click and you see a scene being rendered as every light is being blend in the frame buffer. And it's cool. And in this case, it's one of the few instance where it was working and it was better than having it static. The question you have to ask yourself when you make it interactive is that does it help people understand my stuff? Or does it make it cooler and more complicated? I mean, the answer is obvious, but it's hard to draw the line. yeah that's true and so throughout your time at, if you come back a bit to what you were discussing earlier, that the fact that you are now the owner of ADB and despite that the fact that there is some things that bite you because of the fact that there is so much written by itself, at the same time, there might be some unique qualities there. So I wonder if there is something there in its network stack. that you've never seen before and that you think is pretty outstanding and that you would like to see more done or a pattern which helps in the network logic or whatever. ⁓ It's hard to answer because it serves such a narrow purpose. Very important, but it's about ADB communication. So how to generalize that with a pattern? don't know. One thing which is really good is that I think they got a lot of good things right. ⁓ Having a server was a good thing because some resources have exclusive access. So for example, Accessing a USB interface. USB interface cannot be shared by multiple process. So you needed to have a central server that was long lived and with command accessing it. So the architecture is sound. The way they multiplexed streams on top of protocols. So they build a protocol on top of that could work on top of TCP or USB. That was also really cool. ⁓ In terms of generalizing things. I cannot really come up with anything. But I know that the way they worked was iterative. So for example, they would write something and it will serve its purpose for a few months and then they will rewrite it. And that was very impressive. And that's how a lot of skilled developers such as ⁓ John Carmack worked. They would just have a prototype, learn from it. and rewrite it until it reached a point where it was solid. And I think that's what they did with ADB. So the thing I would recommend to people is not really a template or a design pattern, but a way to work, which has worked well. But it requires two things. The first, requires you to be really kind of fast. If you do too many errors, like off by one and you lose yourself, like memory corruption, it's going to... It's not going to be practical. cannot do that. ⁓ think John Carmack was pretty modest when he mentioned that he wrote something. He made it sound like he wrote Doom with just basic high school trigonometry. But one of the things he had for himself, I think, is that he didn't make too many mistakes. He was able to move very fast and iterate. And that's what they did with ADB. They had a very a star coder, Sweatland, and he proceeded this way. I was told that the way he worked was actually very impressive. He will start at the top of the file and write everything, all the functions from top to bottom, and then compile, and it will work. And that kind of thing just blew my mind. So, yeah, not a template, but more of a methodology. I'm sure he trade a lot in his head as well. yeah, that's a true craftman at work. I like to see that kind of stuff for sure. And I take away the advice and it's also what I sometimes tell people, it's like each time you rewrite something, you basically also master the topic a bit better. And so the next version will be better. So it's not a matter of overthinking too much about the first design, but more like apply your knowledge, apply the skills you have so far and the mastery you have over the topic, implement it. It will serve its purpose. But then after a while, you will have learned more about the topic and you have also have some more like now maybe production experience with this module, with this library, with this binary and maybe apply it knowledge and rewrite it or the part that needs to be improved or is beyond its design limits by now. Yeah. So in, term of iteration speed, when I mentioned that people just were able to write something top to bottom and then to just work. I think it's something that's doable in C. I actually, I'm not sure it's possible to do it in Rust or maybe I'm not, I read many report of people online who have been working with Rust many years and they're like, I still get cut by the code, the, borrower checker. like my design doesn't work and stuff like that. So you've been working in words for 10 years. Do you think you, you, you have a, it's possible to reach a level of proficiency where you are something from top to bottom and it's like the broad checker never catch you. I don't think so, but it's also I think it's also on purpose because you kind of learn to rely on it right like it's it's it's kind of like your second conscious and in in let's say in C you you wouldn't really do that like I mean I never saw the compiler as an ally to me because like pretty much anything could pass in the C compiler and you And it's very subtle sometimes. Like sometimes, I mean, like I said, I have, and I really, and I really was programming mostly just in CEC plus in the first half of my career. and like sometimes you can, let's say you just have some kind of maybe you're playing a const with something or like your pointer is now not a const pointer or I don't know, there are very subtle details and you can easily overlook them and and you wouldn't even be able to check your compiler output either because like... Maybe I was just working in bad code bases, but I remember they were always full of warnings and you had to kind of like learn from the senior people like, yeah, those are all the warnings you need to ignore and those you pay attention to. It's very easy to then like forget some important warnings, even though maybe there should be errors if they can make your program not work or something like that. But I think in Rust you kind of like rely on it. And of course there are also things where Like as a human you can probably be pretty certain or at least you might be you think you're pretty certain that that should be able to be allowed but because the the borrow checker cannot verify it it doesn't allow it and and then yeah, I don't know like I Depends if it's simple enough not it depends what kind of file it is. I'm not sure what what kind of file we're discussing here, but So you think it's not possible. Because I think if you're the kind of code that most people write, which isn't like, I don't know, like a low level voodoo magic where you also need to go into, yeah, try to work around your borrow checker. I mean, that's where this kind of things happens. Like most people write business logic and I think indoors, I think it is possible. I don't think you have to worry about it. in that kind of code like the only times when I'm still being called by the Bolochecker is when I'm trying to be clever or need to try to do something very optimized and I need to kind of like step outside the bounds of what the Bolochecker can do and then there are other kind of tools like Miri and all kind of other things which can help you there but If you write a typical kind of code, which is your business logic, I do think it's possible, yes. Then you wouldn't... I don't think I'm ever surprised till there. So there is hope for you. I mean, yeah. is a hope. I like that. That's what dies at last in the main hope. Yeah, I mean that that's what I'm often confused about because we like often I don't know like whatever is the messaging around Rust and this evangelism I don't really buy for me just a tool and I never see people being on to just take about screwdrivers. So I wonder why people are so on to just take about programming languages for me is a tool. But what I do think is I mean if if if there my program compiles and I have also a sufficient amount of like unit tests testing actually like like kind of like business logic like maybe things which as much as possible you try to codify in your type system, but sometimes you cannot. And like, I mean, in the end, will be some business logic that is just, you need to verify and test speed, ⁓ unit test or integration test. But so I make sure I have those kinds of sets and the combination of the tooling that comes with Rust, like just its compiler capabilities and then the filling the gaps with some tests. Yeah. Whenever I then at that point I can just refactor code base and it also just work. That is maybe different from your question where you say like maybe the compiler will complain and have to iterate a couple of times with the compiler, but in a way for me that's a superpower, not an annoyance because. if I would do that kind of refactor, let's say in C or even in a memory safe language like Go or Python, then I would be very paranoid and I would be very scared and I would definitely not try to just ship it because I would totally not trust if I didn't make some kind of ⁓ mistake as edge cases might be. But yeah, I think you can be very proficient in it and very fast in it. ⁓ But it's a matter of time, I guess. But yeah, if you come from COC +, I would think that you will have a good time. would think, and it seems that you have a good time. I think we talked about a lot already and at the end of the episode I always want to let my guest give some opportunity to maybe if you want to plug in something or maybe we talked about something or we didn't talk about something and you do want to talk about it now or you want to expand on something we talked before so now is definitely an opportunity for that. No, you know, I don't do a lot of self-promotion. For example, my website, one of the thing on my website is that there are no analytics. I don't measure the traffic. I just put things out there and hope people ⁓ can find it interesting, maybe. So I would just say keep being curious. As you mentioned, keep being kind to each other. ⁓ We need it a lot in these times. And that's it. That's all I have to say. Okay, we thank you for your time Fabien, like I hope you will keep finding the energy to ride these deep dives. Maybe, I think we got confirmation from you that you're gonna ride an mDNS book, so I'm already gonna pre-order that one. And I wish you all the best in the rest of your life. Thank you very much. Thank you for having me. Elizabeth (Plabayo)
59:23 | 🔗
Netstack.fm is brought to you by Plabayo building secure, open, and resilient infrastructure with Rust protocols, and purpose. This show is also made possible by Rama, the open source networking framework. Plabayo offers service contracts and welcome sponsorships to keep building and supporting its ecosystem. The theme music of this podcast was composed by DJ Mailbox. If you enjoyed this episode, don't forget to subscribe on your favorite podcast platform and leave a five-star review. It really helps others discover the show. Thanks for tuning in. We'll see you next time for the next handshake.