WEBVTT NOTE This file was generated by Descript 00:00:14.100 --> 00:00:17.220 Amanda Majorowicz: This is Self-directed Research after a bit of a hiatus. 00:00:17.220 --> 00:00:18.450 We're back for season two. 00:00:19.110 --> 00:00:21.390 Make sure to like, follow and subscribe wherever you find us 00:00:21.390 --> 00:00:26.340 to stay up to date and as usual, visit sdr podcast.com/episodes for 00:00:26.340 --> 00:00:29.340 all of the presentations, videos, show notes, and transcripts. 00:00:29.985 --> 00:00:31.635 This episode is sponsored by Depot. 00:00:31.815 --> 00:00:36.075 Listen at the end for more information in this episode, James Presents 00:00:36.105 --> 00:00:38.475 proxying is just dumb routing. 00:00:45.045 --> 00:00:46.004 Amos Wenger: I think everyone's okay. 00:00:46.004 --> 00:00:46.965 Can you hear me fine, James? 00:00:47.565 --> 00:00:48.555 James Munns: I can hear you just fine. 00:00:48.705 --> 00:00:49.095 Amos Wenger: Cool. 00:00:49.155 --> 00:00:52.515 Alright, James, welcome back to season two of SDR. 00:00:53.025 --> 00:00:54.315 What do you have for us today, James? 00:00:54.660 --> 00:00:57.900 James Munns: So, have I already told you that my brain thinks in terms of 00:00:57.900 --> 00:01:03.120 like X is just Y, like that's kind of integral to my learning experience is I 00:01:03.120 --> 00:01:05.340 go, "Oh, this is like that other thing." 00:01:05.925 --> 00:01:06.795 Amos Wenger: I have noticed that. 00:01:06.795 --> 00:01:07.095 Yes. 00:01:07.095 --> 00:01:10.065 So proxying is the uber of routing is what you're saying? 00:01:10.875 --> 00:01:13.935 James Munns: I don't- oh God, I don't know how to pitch this as a startup deck. 00:01:14.205 --> 00:01:17.785 I've been working a lot on proxying, both for River and then Poststation, 00:01:17.805 --> 00:01:23.265 this app that I'm developing for embedded systems is also very proxying based 00:01:23.365 --> 00:01:27.414 in that it's kind of the bridge to all of your devices and things like that. 00:01:27.485 --> 00:01:30.695 I think I've even mentioned on episodes before, I've tried to make a routing 00:01:30.695 --> 00:01:32.745 or a whole networking stack, really. 00:01:32.745 --> 00:01:32.835 Yes. 00:01:32.985 --> 00:01:35.175 And routing is a pretty important part of that. 00:01:35.265 --> 00:01:38.355 And always kind of like, there's always something where I got my feet tangled 00:01:38.355 --> 00:01:41.145 up on and routing is one of them. 00:01:41.505 --> 00:01:45.615 And so I ended up leaning really hard into proxying for Poststation 00:01:46.005 --> 00:01:49.965 and kind of realized after I had everything wired up that I actually got. 00:01:50.270 --> 00:01:52.370 Real close to what you would want out of routing. 00:01:52.370 --> 00:01:55.010 So today is just proxying is just dumb routing. 00:01:55.190 --> 00:01:55.610 Amos Wenger: Okay. 00:01:55.730 --> 00:02:00.634 But you know, like when you say proxying, I think about, yeah, I mean HTTP proxying, 00:02:00.690 --> 00:02:01.890 is that what we're gonna talk about today? 00:02:01.890 --> 00:02:05.130 Or are we talking more low level stuff like postcard-rpc based? 00:02:06.000 --> 00:02:08.000 James Munns: I mean, it's gonna be around postcard-rpc 'cause that's 00:02:09.000 --> 00:02:12.000 literally what I've been doing since the last time we recorded an episode is I- 00:02:12.100 --> 00:02:16.940 Amos Wenger: but you're also writing a reverse HTTP proxy, so that's, I dunno. 00:02:17.060 --> 00:02:17.480 James Munns: It's true. 00:02:18.149 --> 00:02:18.500 But yeah, I mean, 00:02:18.500 --> 00:02:19.010 Amos Wenger: That's where my mind goes. 00:02:19.010 --> 00:02:22.410 That's why I ask these questions, James, but sure. 00:02:22.559 --> 00:02:25.179 James Munns: Effectively they're very similar. 00:02:25.279 --> 00:02:28.769 But routing does a lot more. 00:02:28.769 --> 00:02:33.319 So it's almost like a proxying is just kind of a sort of subset of routing. 00:02:33.194 --> 00:02:36.594 So like normally when we're talking exactly like you're talking about 00:02:36.594 --> 00:02:41.334 HTTP devices, the internet, we've got computers everywhere and you generally, 00:02:41.334 --> 00:02:45.084 your computer doesn't know exactly how to get to Google servers or to 00:02:45.084 --> 00:02:48.264 get from my computer to your computer because all other computers are just 00:02:48.264 --> 00:02:50.244 somewhere else, even on your computer. 00:02:50.244 --> 00:02:53.585 The answer is just, it's somewhere else. 00:02:53.645 --> 00:02:55.804 When we send a message or a packet or something, we just 00:02:55.804 --> 00:02:56.885 send them to somewhere else. 00:02:56.885 --> 00:03:00.795 We say like- we have a vague idea, like when we do DNS, we might get 00:03:00.795 --> 00:03:04.174 an IP address, and then we kind of just write it on the outside of the 00:03:04.174 --> 00:03:08.984 envelope and drop it in the outgoing mailbox and hope it gets there. 00:03:08.984 --> 00:03:12.065 We really like the computer, has no idea how it gets there, but it knows the 00:03:12.065 --> 00:03:18.010 destination and it just says "Go." And this is like generally how any computer 00:03:18.010 --> 00:03:23.725 can talk to any other computer as long as you have some concept of the destination, 00:03:23.755 --> 00:03:27.715 like an IP address or DNS address that gets turned into an IP address. 00:03:27.985 --> 00:03:31.435 You just kind of yeet it out onto the internet and it gets to the 00:03:31.435 --> 00:03:35.485 other side because routing is the thing that figures it out. 00:03:35.575 --> 00:03:35.665 Mm-hmm. 00:03:36.085 --> 00:03:38.635 And routing is one of those, like "it's a whole thing" topics. 00:03:38.635 --> 00:03:39.685 There are many- 00:03:39.685 --> 00:03:40.555 Amos Wenger: It absolutely is. 00:03:40.555 --> 00:03:44.245 James Munns: PhD careers in engineering and company whose 00:03:44.245 --> 00:03:48.869 entire jobs are to just think about routing of how you manage that. 00:03:48.929 --> 00:03:52.560 And a lot of it comes down to like, you only have so much 00:03:52.560 --> 00:03:55.179 overview of even an IPv4. 00:03:55.200 --> 00:03:57.660 You've got 32 bits, 4 billion addresses. 00:03:57.660 --> 00:03:59.720 If you had to keep information on all 4 billion of those devices 00:03:59.770 --> 00:04:04.980 up until maybe the last decade or two, that would be very difficult. 00:04:04.980 --> 00:04:07.730 And now that there's IPv6 it's, you know, even more outstandingly difficult. 00:04:07.850 --> 00:04:11.880 Amos Wenger: And so much of the knowledge around routing is kept. 00:04:11.940 --> 00:04:15.420 'Cause not many people really need to know about it. 00:04:15.470 --> 00:04:18.869 I've been in some circles where people have said, "Ah, it's always 00:04:18.869 --> 00:04:20.299 DNS," when something goes out, there's an out on the internet. 00:04:20.450 --> 00:04:24.050 But then you run into some deeper circles of hell where people say, "Oh, 00:04:24.050 --> 00:04:27.625 If it's not DNS, it's BGP," and you're like, "Wait a minute, what's BGP?" 00:04:27.625 --> 00:04:30.505 And then people found out about BGP because of some major outages. 00:04:30.685 --> 00:04:33.985 But then when you look at how it's actually done in the big router 00:04:33.985 --> 00:04:36.245 companies... it's frightening. 00:04:36.275 --> 00:04:37.085 It's very scary. 00:04:37.325 --> 00:04:39.575 James Munns: And routing is another one of those things where there's like, as 00:04:39.575 --> 00:04:44.525 it's described by the RFCs, like the internet RFCs for them, and then there's 00:04:44.525 --> 00:04:45.935 what actually happens in practice. 00:04:45.165 --> 00:04:49.465 In the same way that you can send certain packets, and it's totally valid according 00:04:49.465 --> 00:04:53.395 to the RFCs, but if you ever go through a Cisco router somewhere in the middle, 00:04:53.395 --> 00:04:54.985 it'll just drop your packet because 00:04:54.045 --> 00:04:54.315 Amos Wenger: Absolutely. 00:04:54.315 --> 00:04:57.985 James Munns: It's technically allowed, but it just says- no, get outta here. 00:04:57.255 --> 00:04:57.495 Amos Wenger: Yep. 00:04:57.525 --> 00:05:00.475 James Munns: And so there's also like those kind of things. 00:05:00.475 --> 00:05:05.805 The big takeaway here, like you said with BGP, is there's this whole system 00:05:05.805 --> 00:05:08.645 where every machine that your packet kind of goes through, every district 00:05:08.645 --> 00:05:12.395 office that it bounces to on the way to its destination, they all have sort 00:05:12.395 --> 00:05:14.660 of a partial view of the internet. 00:05:14.660 --> 00:05:17.240 Usually, like they're direct neighbors and then maybe some big 00:05:17.240 --> 00:05:20.690 picture things that's where like BGP comes in and things like that. 00:05:20.690 --> 00:05:24.590 And they'll have routing tables and no one ever has a complete picture 00:05:24.680 --> 00:05:29.180 of, or most commodity hardware has no idea of the entire internet. 00:05:29.180 --> 00:05:33.640 They just have like, "Where is the next step?" And then maybe like 00:05:33.640 --> 00:05:35.885 some big picture version of that. 00:05:35.065 --> 00:05:38.895 Amos Wenger: Well, and the thing is, there's no, when I looked into traceroute 00:05:38.915 --> 00:05:41.915 and that kind of thing, first of all, traceroute is not representative 00:05:41.975 --> 00:05:43.535 of how packets are actually routed. 00:05:43.535 --> 00:05:44.645 There's something I discovered recently. 00:05:44.645 --> 00:05:46.225 There's a whole page about how it's actually fricking useless, and 00:05:46.225 --> 00:05:49.805 if you notice that there's drops somewhere, it doesn't actually 00:05:49.805 --> 00:05:50.035 mean that there's a problem there. 00:05:50.035 --> 00:05:53.795 It could just mean that they're ignoring your ICMP packets because they are 00:05:53.795 --> 00:05:56.975 big routers and they have other stuff to do, like routing, actual traffic. 00:05:56.980 --> 00:05:59.460 James Munns: Was it Mara or someone made, someone made a traceroute implementation 00:05:59.460 --> 00:06:02.350 that made all of the times go backwards? 00:06:02.650 --> 00:06:06.310 Because it's like exactly what you're saying is it's just a payload in a packet 00:06:06.430 --> 00:06:07.140 and turns out you can lie on the internet. 00:06:07.140 --> 00:06:10.300 And you can just put the timestamp in history. 00:06:10.360 --> 00:06:10.500 Amos Wenger: There's different techniques. 00:06:10.505 --> 00:06:10.655 Yeah. 00:06:10.660 --> 00:06:10.860 Yeah. 00:06:10.860 --> 00:06:12.820 'cause it's just the TTL. 00:06:12.820 --> 00:06:17.270 Traceroute with ICMP packets is a hack. 00:06:17.450 --> 00:06:21.920 So routers are not obligated by standards or whatever to actually respect that. 00:06:21.920 --> 00:06:25.730 You can do trade fraud by UDP, but then that's not the same thing as TCP, which 00:06:25.730 --> 00:06:30.750 is what most applications use- ah, that's not true anymore 'cause of HTTP/3. 00:06:30.770 --> 00:06:31.190 Darn it. 00:06:31.220 --> 00:06:33.590 The point I was getting at was that... 00:06:33.620 --> 00:06:34.970 James Munns: You were too QUIC to say that 00:06:34.890 --> 00:06:36.860 Amos Wenger: Frigging Google. 00:06:36.610 --> 00:06:40.650 James Munns: For Amanda QUIC is the original name of HTTP/3. 00:06:40.670 --> 00:06:40.760 Amos Wenger: Oh. 00:06:40.760 --> 00:06:42.650 I didn't even freaking catch the joke. 00:06:42.710 --> 00:06:43.430 Well played James. 00:06:43.060 --> 00:06:44.150 Touche. 00:06:44.140 --> 00:06:46.330 James Munns: I'm glad I explained that 00:06:46.330 --> 00:06:48.640 Amos Wenger: As the Americans say, pretending to be French, touche. 00:06:48.640 --> 00:06:50.980 James Munns: That means it's staying in the, uh, in the episode. 00:06:50.980 --> 00:06:51.520 Amos Wenger: It probably is. 00:06:51.680 --> 00:06:53.150 I had another point, I swear. 00:06:53.190 --> 00:06:54.800 Traceroute... something. 00:06:54.950 --> 00:06:58.730 Yes, oh, there is no- like, because it's distributed systems and I'm sure you were 00:06:58.730 --> 00:07:01.730 getting to this and I'm stealing the, the, the limelight on your episode, but 00:07:01.940 --> 00:07:03.650 there is no one version of the truth. 00:07:03.730 --> 00:07:07.570 Studying the internet is, is being a historian. 00:07:07.570 --> 00:07:11.215 I don't know what's the closest thing, but you just go around and you try 00:07:11.215 --> 00:07:15.635 to ask questions of things and gather data, and you have some incomplete 00:07:15.635 --> 00:07:16.835 everchanging version of the truth. 00:07:16.865 --> 00:07:19.705 And depending on where you stand, when you ask a question, you get different answers. 00:07:19.755 --> 00:07:22.325 And you don't know what's going on in certain countries that are- in 00:07:22.325 --> 00:07:25.055 different countries that have different policies about different things. 00:07:25.055 --> 00:07:25.056 Yeah. 00:07:25.415 --> 00:07:28.125 James Munns: And it's one of those things, it just takes effort and 00:07:28.130 --> 00:07:30.750 it's how the internet has evolved. 00:07:30.810 --> 00:07:31.070 It tends to work fairly well. 00:07:31.450 --> 00:07:35.160 But it means that you need to have sort of an idea of where things are 00:07:35.160 --> 00:07:38.770 and you need to keep track of that because they do change over time. 00:07:38.100 --> 00:07:45.965 And for embedded devices, particularly small devices, that's state and 00:07:45.965 --> 00:07:47.815 things that you have to do to keep up with figuring out where they are. 00:07:47.935 --> 00:07:50.965 You know, I heard this report about this, but has that timed out? 00:07:50.965 --> 00:07:52.425 Have I gotten newer, conflicting information? 00:07:52.665 --> 00:07:54.775 Figuring out all these things. 00:07:54.775 --> 00:07:57.805 So you've got your little device that's a sensor or whatever, and it wants 00:07:57.805 --> 00:07:59.005 to send something over the internet. 00:07:59.005 --> 00:08:03.415 You have to go, "Okay, I would like to put a destination on 00:08:03.415 --> 00:08:06.085 this. Where do I send this?" 00:08:06.385 --> 00:08:08.635 And in some cases it's just hardcoded. 00:08:08.635 --> 00:08:12.685 You just send to a place and someone else will figure it out. 00:08:12.955 --> 00:08:15.775 But if you'd like to do any kind of networking locally where you're like: 00:08:15.775 --> 00:08:17.835 well, sometimes I send it over here over my wireless network and sometimes 00:08:17.835 --> 00:08:21.895 over, you know, the serial bus that I have over here, you kind of have to 00:08:21.895 --> 00:08:25.335 keep track of some things, and that's not always easy for small devices. 00:08:25.335 --> 00:08:28.335 It's very possible you can get little wifi devices and things like that. 00:08:28.335 --> 00:08:32.965 But like a TCP/IP stack that does the bare minimum of routing takes 00:08:32.965 --> 00:08:37.665 up a non-trivial amount of your CPU cycles and memory and Yeah, and 00:08:37.665 --> 00:08:38.135 code storage and things like that. 00:08:38.135 --> 00:08:40.365 Amos Wenger: And it's probably way overkill. 00:08:40.535 --> 00:08:43.135 James Munns: Well, you know... devices are going that way. 00:08:43.235 --> 00:08:45.615 What was overkill a while ago. 00:08:45.034 --> 00:08:48.615 Devices are getting fast and cheap and powerful. 00:08:48.615 --> 00:08:48.975 So... 00:08:49.034 --> 00:08:49.235 Amos Wenger: I guess so. 00:08:49.385 --> 00:08:49.804 Yeah. 00:08:50.804 --> 00:08:53.985 Have we talked about Collapse OS on the- I'm sorry to hijack 00:08:53.985 --> 00:08:55.155 your presentation once again. 00:08:55.215 --> 00:08:56.145 James Munns: No, I don't think we have. 00:08:56.294 --> 00:08:57.855 I've seen a bunch of projects like that though. 00:08:57.855 --> 00:09:00.534 Is that, is that the one that like bootstraps from Forth 00:09:00.554 --> 00:09:01.695 or is that a different one? 00:09:01.855 --> 00:09:06.510 Amos Wenger: I think it's a different one, but I see the one you're thinking of. 00:09:06.510 --> 00:09:11.370 Mine is just, um, if there is an apocalypse and we suddenly 00:09:11.370 --> 00:09:12.930 live in a post apocalypse world. 00:09:12.290 --> 00:09:14.450 Uh, we are gonna lose computing. 00:09:14.570 --> 00:09:18.570 And it's, it's a shame 'cause for modern computing to exist, 00:09:18.600 --> 00:09:19.040 there's so many prerequisites. 00:09:19.130 --> 00:09:22.130 But what they notice is that even though we're probably not gonna be able to 00:09:22.130 --> 00:09:27.480 make chip from scratch again for a very long time, it is ever, there's a ton 00:09:27.510 --> 00:09:31.890 of 16 bits, chips that you can scavenge from a lot of different equipments. 00:09:31.040 --> 00:09:33.870 And so they're developing for that. 00:09:33.870 --> 00:09:38.280 Essentially it was like you go around, you get 16 bit chips from various places 00:09:38.280 --> 00:09:41.400 and you can actually assemble them manually with like wires and stuff. 00:09:41.400 --> 00:09:43.710 'Cause it's still like this- what is it called? 00:09:43.710 --> 00:09:45.060 Is it pinball package? 00:09:45.120 --> 00:09:45.960 I don't know exactly what it's called. 00:09:45.960 --> 00:09:47.910 James Munns: Are you talking about like DIP ones that you that have 00:09:48.030 --> 00:09:49.560 Yeah, the dual in-line package. 00:09:49.560 --> 00:09:49.620 Amos Wenger: Yeah. 00:09:49.650 --> 00:09:50.640 It's still human scale. 00:09:50.640 --> 00:09:53.400 You can work it with your fingers and like connect them to things. 00:09:53.430 --> 00:09:54.840 And that's their premise. 00:09:55.135 --> 00:09:58.225 I remember needing to take a minute after finding that website, like, wow, 00:09:58.225 --> 00:10:01.435 some people have put some thought, when I see doomsday preppers with a 00:10:01.435 --> 00:10:04.835 lot of canned goods, I'm like, "This is gonna last you two weeks and you're 00:10:04.835 --> 00:10:05.755 gonna get eaten by your neighbors." 00:10:05.755 --> 00:10:06.415 James Munns: This is exactly what I was gonna draw. 00:10:06.415 --> 00:10:06.420 Amos Wenger: Yeah. 00:10:06.689 --> 00:10:06.730 Whatever. 00:10:06.775 --> 00:10:08.505 But when I see that, I'm like, "Huh...." that's more realistic 00:10:08.505 --> 00:10:10.525 and more scary to me somehow. 00:10:10.790 --> 00:10:13.390 James Munns: Yeah... it's challenging as someone who likes building the world 00:10:13.390 --> 00:10:18.939 from scratch and does it as a hobby, there's a lot to build, especially if 00:10:18.939 --> 00:10:21.609 you're at the point where you can't just buy things off the shelf either. 00:10:21.659 --> 00:10:24.759 Yeah, I've seen that and I've seen a couple of other ones where 00:10:24.759 --> 00:10:26.129 you're like, okay, if I can get something that can compute some 00:10:26.129 --> 00:10:28.409 numbers, how can I work back up? 00:10:28.409 --> 00:10:30.629 And I've, I've seen one that bootstrapped itself from like. 00:10:30.999 --> 00:10:37.939 assembly to forth to Python, and then maybe a C compiler at some point in 00:10:37.939 --> 00:10:41.989 there, where if you have some kind of device that can run forth, or if you can 00:10:41.989 --> 00:10:45.619 write enough assembly to get a forth, you can write enough forth to get a Python, 00:10:45.829 --> 00:10:48.009 and you can write enough Python to make a C compiler or something like that. 00:10:48.009 --> 00:10:50.929 It was an impressive set of bootstrapping, 00:10:50.989 --> 00:10:53.294 Amos Wenger: But James... Why would you want a Python? 00:10:53.744 --> 00:10:55.789 Sorry, this is a weird step. 00:10:56.269 --> 00:10:59.659 I can forgive C, but I draw the line at Python C. 00:10:59.659 --> 00:11:01.680 Amanda Majorowicz: Hang on... this is not the right podcast. 00:11:01.680 --> 00:11:04.499 We got- it's a different one, different podcast for Python. 00:11:05.069 --> 00:11:05.430 James Munns: Okay. 00:11:05.430 --> 00:11:08.219 So if I'm gonna make the claim routing is too hard for these 00:11:08.219 --> 00:11:11.830 small little guys that I write code for, then what about proxying? 00:11:11.860 --> 00:11:14.270 So we've talked about proxying. 00:11:14.270 --> 00:11:17.870 Most people have probably heard of proxying if you've done backend stuff. 00:11:17.895 --> 00:11:19.660 Proxying is the Nginx. 00:11:19.680 --> 00:11:22.469 The River, the Apache 2 that you put in front of your production servers. 00:11:22.620 --> 00:11:25.479 Amos Wenger: James, I like you, but did you just sneak up 00:11:25.479 --> 00:11:26.680 your own work between those? 00:11:27.240 --> 00:11:28.589 You could have mentioned Caddy. 00:11:28.680 --> 00:11:31.810 Caddy's mainstream ish. 00:11:31.829 --> 00:11:34.759 James Munns: Yeah, I probably shouldn't 'cause I'm not 00:11:34.759 --> 00:11:35.049 actively working on it right now. 00:11:35.049 --> 00:11:35.284 But like, 00:11:36.104 --> 00:11:37.089 Amos Wenger: Do you wanna mention, 00:11:37.509 --> 00:11:38.259 James Munns: I'll take it again. 00:11:38.439 --> 00:11:39.189 I'll take it again. 00:11:39.189 --> 00:11:41.869 Amos Wenger: No, you can- no, let's keep it. 00:11:41.989 --> 00:11:44.199 I'm just think, do you wanna mention why people, why it's advised to have a 00:11:44.199 --> 00:11:46.059 proxy in front of your web application? 00:11:46.680 --> 00:11:49.900 James Munns: You would probably know better than I would, but I just wanna 00:11:49.900 --> 00:11:51.729 talk about what proxying is first. 00:11:51.759 --> 00:11:52.599 Amos Wenger: You can do that. 00:11:52.719 --> 00:11:55.389 James Munns: Proxying in general is you put a computer in front of your computer. 00:11:55.550 --> 00:11:59.270 When a client wants to talk to who they think is the server, what they end up 00:11:59.270 --> 00:12:04.160 talking to is a proxy who gets their first chance to either terminate the TLS 00:12:04.160 --> 00:12:08.030 connection to do some kind of security check to say, hey, you're asking for 00:12:08.030 --> 00:12:12.020 things that you should not ask for, to do authentication, and then usually 00:12:12.020 --> 00:12:16.070 that proxying agent is sort of like a bouncer, and if they decide to pass that 00:12:16.070 --> 00:12:17.720 on, then they're gonna pass that on. 00:12:17.780 --> 00:12:21.720 And they could also do the job of load balancing. 00:12:21.720 --> 00:12:23.690 There's a lot of different reasons you'd use it for proxying, so that 00:12:23.720 --> 00:12:28.100 first server might just say, okay, well I've got 10 people in the back. 00:12:28.130 --> 00:12:31.980 You're gonna go to desk number four to get your request served 00:12:31.980 --> 00:12:32.090 because they're the least busy. 00:12:32.240 --> 00:12:35.670 Amos Wenger: In the explanation you just gave, there is one word 00:12:35.670 --> 00:12:38.250 that gives away that you have been working on reverse proxy. 00:12:38.580 --> 00:12:39.450 Do you know which one it is? 00:12:39.550 --> 00:12:40.090 Terminate. 00:12:40.120 --> 00:12:40.600 James Munns: Terminate. 00:12:40.630 --> 00:12:42.170 Yeah, it's a good one. 00:12:42.170 --> 00:12:44.700 Amos Wenger: 'Cause when you tell people, "I'm gonna terminate 00:12:44.700 --> 00:12:45.890 your connection," what they think is you're gonna cut it off. 00:12:46.010 --> 00:12:46.250 Yeah. 00:12:46.250 --> 00:12:49.250 But what it actually means in that context, terminating TLS means 00:12:49.250 --> 00:12:54.840 we're gonna do the last bit of work that takes all HTTP traffic and 00:12:54.840 --> 00:12:56.490 and encrypts it and decrypts it. 00:12:56.640 --> 00:12:59.370 James Munns: I think this is one of those old telephone network rules. 00:12:59.400 --> 00:13:00.120 'cause when you talk about- 00:13:00.415 --> 00:13:00.495 Amos Wenger: Probably. 00:13:00.495 --> 00:13:03.330 James Munns: Talk about terminating like a connection, it's literally 00:13:03.330 --> 00:13:07.020 where you've connected it onto some device or something like that. 00:13:07.020 --> 00:13:07.290 So I think- 00:13:07.290 --> 00:13:08.220 Amos Wenger: It's the last mile or something. 00:13:08.220 --> 00:13:08.670 Yeah. 00:13:08.670 --> 00:13:08.730 Yeah. 00:13:08.730 --> 00:13:11.310 I was just putting myself in the shoes of someone who has not worked 00:13:11.310 --> 00:13:14.520 on such a proxy, because we both have, and that's the word that stood out. 00:13:14.580 --> 00:13:14.640 Yeah. 00:13:14.640 --> 00:13:17.730 Amanda Majorowicz: This is also very helpful for me because that's exactly 00:13:17.730 --> 00:13:21.940 how I was picturing it until you explained it to me, so thank you. 00:13:21.060 --> 00:13:22.630 Amos Wenger: Thanks, Amanda. 00:13:22.630 --> 00:13:22.930 James Munns: Gotcha. 00:13:23.140 --> 00:13:25.990 Yeah, and so really it just means there's a computer in front of 00:13:25.990 --> 00:13:26.400 another computer, is proxying. 00:13:26.490 --> 00:13:30.360 It means you are transparently talking to something in front of what you actually 00:13:30.360 --> 00:13:34.060 think that you are talking to, and in a lot of cases this isn't even exposed. 00:13:34.060 --> 00:13:34.810 You wouldn't know. 00:13:34.810 --> 00:13:37.030 There's no like hint, Hey, I'm talking to a proxy. 00:13:37.270 --> 00:13:40.750 The idea is that ideally, most of the time it just is transparent. 00:13:40.870 --> 00:13:43.050 And this gets used a lot on the internet for client server interactions. 00:13:43.050 --> 00:13:48.670 When your laptop connects to a server somewhere, it's the client and the server 00:13:48.670 --> 00:13:50.040 is the server that it's talking to, and. 00:13:50.330 --> 00:13:55.680 These get used a lot for proxying because when there's this direction 00:13:55.680 --> 00:13:58.560 to it, it means that when you go in, you talk to the bouncer that gets 00:13:58.560 --> 00:14:02.520 passed on, the person on the inside passes it back to the bouncer and back. 00:14:02.640 --> 00:14:06.270 If you were doing a true peer-to-peer connection, it's a little more difficult. 00:14:06.330 --> 00:14:09.450 Then you're kind of a full blown router at that point because you're doing kind of 00:14:09.450 --> 00:14:14.190 like anyone-to-anyone connections, where proxying is more specifically like someone 00:14:14.190 --> 00:14:18.300 on the outside comes in, gets bounced to someone privately on the inside. 00:14:18.540 --> 00:14:22.550 Someone on the inside privately replies, and then that gets 00:14:22.550 --> 00:14:23.600 taken back to the client. 00:14:23.610 --> 00:14:25.280 There's other cases where this isn't the case. 00:14:25.280 --> 00:14:28.350 If we're talking about more proxies, there's like 00:14:28.440 --> 00:14:29.090 internal, what are they called? 00:14:29.360 --> 00:14:31.280 Sidecar proxies get used a lot. 00:14:31.340 --> 00:14:35.430 And that's for like mutual authentication, where you both have your own bouncer 00:14:35.430 --> 00:14:38.340 that sets up a secure connection between you and things like that. 00:14:38.340 --> 00:14:38.400 Yeah. 00:14:38.430 --> 00:14:40.465 But that's... a totally different topic. 00:14:40.585 --> 00:14:42.685 Amos Wenger: I was confused about that for the longest time. 00:14:42.685 --> 00:14:45.175 So it's possible that I'm still confused about it, but I think 00:14:45.175 --> 00:14:47.335 we are defining reverse proxies. 00:14:47.335 --> 00:14:52.505 You're thinking of the thing that is like Google front-end, or you mentioned 00:14:52.505 --> 00:14:56.585 Nginx for something that often has a one or a few websites behind it. 00:14:56.825 --> 00:15:00.665 There's also forward proxies, but those are not as used as they used to be. 00:15:00.205 --> 00:15:01.910 Wow, that's a lot of "use". 00:15:01.910 --> 00:15:02.195 James Munns: Yeah, that's true. 00:15:02.285 --> 00:15:05.615 Amos Wenger: They used to be used to accelerate connections. 00:15:05.615 --> 00:15:08.605 You, you'd have like, you'd run Squid locally and it would cache 00:15:08.605 --> 00:15:10.345 the internet for you and it would just be served from disk instead. 00:15:10.435 --> 00:15:13.165 James Munns: I think like internal business networks used to use those too. 00:15:13.165 --> 00:15:14.005 Amos Wenger: I think some still do... 00:15:14.005 --> 00:15:16.865 James Munns: like all your outgoing connections went through 00:15:16.865 --> 00:15:17.795 a bouncer and things like that. 00:15:17.795 --> 00:15:20.125 So yeah, you're right- I'm mostly talking about reverse proxying. 00:15:20.125 --> 00:15:23.165 But there are definitely a couple flavors of proxying. 00:15:23.710 --> 00:15:25.570 Amos Wenger: And I'm just gonna answer my own question 'cause I raised it. 00:15:25.710 --> 00:15:30.230 One of the reasons you might want, you do want a reverse proxy, is because 00:15:30.320 --> 00:15:33.560 your application probably only speaks HTTP/1, first of all, but you wanna 00:15:33.560 --> 00:15:35.270 serve HTTP/2 and 3 to the outside. 00:15:35.360 --> 00:15:37.640 You're not gonna want to worry about TLS. 00:15:37.640 --> 00:15:38.840 Translation is a big part of it. 00:15:38.900 --> 00:15:42.735 And thirdly, performance also, if you have a bunch of different nodes 00:15:42.735 --> 00:15:46.845 around the world that can do the TLS handshake with your clients and then 00:15:46.845 --> 00:15:49.425 talk to your application, even if your application itself is only in one 00:15:49.425 --> 00:15:53.455 location, that's still gonna speed up the initial handshake and exchange. 00:15:53.755 --> 00:15:55.945 And then also just because the internet is a scary place. 00:15:55.365 --> 00:15:57.835 Like when the internet first started. 00:15:57.335 --> 00:16:01.355 Before everyone got on it, it was just like, "Yay, we can exchange information!" 00:16:01.355 --> 00:16:05.075 But now it's, as soon as an IP comes live and starts accepting connection, 00:16:05.075 --> 00:16:07.755 it's like, are you a PHP thing? 00:16:07.755 --> 00:16:08.985 Can you leak credentials? 00:16:08.985 --> 00:16:10.485 I'm gonna try all the known paths. 00:16:10.485 --> 00:16:10.715 James Munns: Are you a WordPress thing? 00:16:10.895 --> 00:16:11.075 Yeah. 00:16:11.375 --> 00:16:15.455 I love seeing those in logs for like their HTTP server and it's like- 00:16:15.485 --> 00:16:17.295 Amos Wenger: I have so many of these. 00:16:17.385 --> 00:16:18.735 James Munns: WP login admin. 00:16:18.735 --> 00:16:23.935 Amos Wenger: So instead of people attacking your application directly 00:16:23.935 --> 00:16:27.865 and potentially finding, I don't know, something in your Python code that makes 00:16:27.865 --> 00:16:31.735 it uses up all the memory, something in your C code that crashes and dumps 00:16:31.795 --> 00:16:36.425 private, user data, you'd rather have them attack Google or Amazon or whatever 00:16:36.425 --> 00:16:37.535 you put in front of your website. 00:16:37.770 --> 00:16:38.280 James Munns: Exactly. 00:16:38.400 --> 00:16:38.640 Yeah. 00:16:38.640 --> 00:16:41.460 And a lot of times there tends to be a lot more security hardening. 00:16:41.460 --> 00:16:45.600 If people use commonly popular reverse proxies like Nginx or 00:16:45.780 --> 00:16:48.480 Apache, there's a lot more work that goes into hardening those. 00:16:48.540 --> 00:16:48.630 Yes. 00:16:48.690 --> 00:16:52.170 Where sometimes people put very squishy application servers behind them that 00:16:52.170 --> 00:16:56.610 go, I haven't thought of all the edge cases like bufferbloat and all of those. 00:16:56.610 --> 00:16:56.880 Amos Wenger: Absolutely. 00:16:56.880 --> 00:17:00.090 James Munns: And you can just configure the... you know, instead of having all 00:17:00.090 --> 00:17:05.280 hundred of your servers be immune to the same, you just have the bouncer. 00:17:05.280 --> 00:17:09.900 Amos Wenger: But on a personal note, I think it's absolutely bonkers that Nginx 00:17:09.900 --> 00:17:13.380 is still the default choice for a lot of people when it's, it's written in C. I 00:17:13.400 --> 00:17:20.290 personally, I'm on the record as like the Go hater and I use Caddy, because I may 00:17:20.290 --> 00:17:22.505 hate Go, but at least it's memory safe. 00:17:22.655 --> 00:17:23.345 So yeah. 00:17:23.375 --> 00:17:23.615 Okay. 00:17:23.615 --> 00:17:27.055 I'm losing out on 10, 15% performance, but I don't know. 00:17:27.055 --> 00:17:28.895 It feels better. 00:17:29.195 --> 00:17:29.555 James Munns: Yeah. 00:17:29.585 --> 00:17:32.495 So I mean we have this sort of proxying setup where there's 00:17:32.495 --> 00:17:33.785 that bouncer in the middle. 00:17:33.845 --> 00:17:36.635 So we have this sort of setup where the client talks to the proxy. 00:17:36.190 --> 00:17:40.950 The proxy in this case appears to be the server. 00:17:40.010 --> 00:17:43.250 So it's acting in the server role, but as soon as it's received that 00:17:43.250 --> 00:17:47.480 request, if it decides to move on, it then turns around to the inside and 00:17:47.540 --> 00:17:49.670 it makes a request to the real server. 00:17:49.820 --> 00:17:51.770 So in that role, it's a client. 00:17:51.775 --> 00:17:51.795 Yep. 00:17:52.010 --> 00:17:54.780 So it essentially kind of does both. 00:17:54.810 --> 00:17:57.380 It pretends to be a server to the outside and then turns around 00:17:57.380 --> 00:17:58.700 and pretends to be a client. 00:17:58.790 --> 00:18:01.190 So we get the, you know, the server talks to the proxy. 00:18:01.190 --> 00:18:04.155 The proxy talks... I screwed this up. 00:18:03.155 --> 00:18:04.565 This is what I get for skipping around slides. 00:18:04.805 --> 00:18:09.595 And then in the other way, when the server replies to the proxy, the proxy 00:18:09.595 --> 00:18:12.955 is the client, and then same, it turns around and pretends to be the server. 00:18:12.955 --> 00:18:17.995 So we just pretend at every step along the way that this is a direct connection. 00:18:17.055 --> 00:18:21.045 So in this case, the internal server knows nothing really about the real 00:18:21.075 --> 00:18:23.875 client unless the proxy passed it on. 00:18:23.935 --> 00:18:26.995 And in the same way, unless the proxy passed it on, the real client knows 00:18:26.995 --> 00:18:30.565 nothing about the real server, which gives you sort of this, you know, 00:18:30.565 --> 00:18:34.455 blinders you can put on where you just say, it's just a direct peer-to-peer 00:18:34.455 --> 00:18:35.075 communication of a client and a server. 00:18:35.165 --> 00:18:38.205 How more simple could it be than that? 00:18:38.295 --> 00:18:41.955 The thing is, we can also use this for embedded devices, and this is exactly what 00:18:41.955 --> 00:18:46.275 I'm doing with Poststation, is instead of having networking and things like that 00:18:46.275 --> 00:18:50.415 on the inside, we make things cheaper by saying, "Well, these devices could 00:18:50.415 --> 00:18:51.245 already do point to point connections." 00:18:51.425 --> 00:18:53.045 You could connect to them directly. 00:18:53.540 --> 00:18:59.460 What Poststation introduces is, okay, well I will be your delegated proxy for this. 00:18:59.610 --> 00:19:02.610 So then Poststation is in charge of talking to the actual embedded 00:19:02.610 --> 00:19:04.580 devices, can speak with them in whatever protocol they'd like. 00:19:04.610 --> 00:19:08.380 And in the same way you were talking about the difference between HTTP/1 00:19:08.400 --> 00:19:12.260 or whatever, it speaks exclusively a very compact, binary format 00:19:12.260 --> 00:19:14.730 of postcard to these devices. 00:19:14.790 --> 00:19:19.040 But you could have your clients speak JSON and REST to Poststation and it will do 00:19:19.040 --> 00:19:21.230 that translation for you and pass it on. 00:19:21.535 --> 00:19:24.385 So we can make a lot of things cheaper because we don't 00:19:24.385 --> 00:19:26.585 have to think about routing. 00:19:26.765 --> 00:19:30.785 We don't have to think about, you know, sending JSON to a tiny microcontroller. 00:19:30.965 --> 00:19:32.185 We don't have to worry about any of those things. 00:19:32.575 --> 00:19:36.355 But the downside is, I said that proxying, at least reverse proxying 00:19:36.355 --> 00:19:40.405 like we're talking about here, there's no real any to any comms here. 00:19:40.465 --> 00:19:44.185 Like if you want a device to talk to a device, and they're in this perfect 00:19:44.185 --> 00:19:48.485 little simple brain world where they only take incoming connections 00:19:48.485 --> 00:19:50.245 from one direction, and then all replies go back in that direction. 00:19:50.720 --> 00:19:55.460 It's more challenging to say: Hey, please send this to a specific person. 00:19:55.520 --> 00:19:59.700 Which if you've set up all of your devices to say: Hey, I receive commands 00:19:59.700 --> 00:20:03.520 and I publish things, you know, everything coming in goes that way and 00:20:03.520 --> 00:20:03.900 everything going out goes that way. 00:20:03.900 --> 00:20:04.830 And life is simple. 00:20:04.890 --> 00:20:05.580 It's great. 00:20:05.640 --> 00:20:09.840 But if you really do want peer-to-peer networking, then it makes things 00:20:09.840 --> 00:20:11.450 a little bit more challenging. 00:20:11.510 --> 00:20:16.280 But often for most microcontrollers or things like that, that's good enough. 00:20:16.310 --> 00:20:18.440 You might have like a small network of devices. 00:20:18.830 --> 00:20:20.000 But they're all doing their job. 00:20:20.030 --> 00:20:22.090 They're running the elbow, the wrist, and the hand motors. 00:20:22.405 --> 00:20:26.525 And the elbow doesn't usually need to talk to the hand very often. 00:20:26.705 --> 00:20:29.015 They're usually all talking back to the brain, and the brain is 00:20:29.015 --> 00:20:30.455 talking back to all of the motors. 00:20:30.725 --> 00:20:30.995 Yeah. 00:20:31.025 --> 00:20:33.815 This is usually good enough, like I said, for website backends, you're 00:20:33.815 --> 00:20:38.165 usually going client to proxy to API server and back down the line. 00:20:38.215 --> 00:20:41.160 That's like the people who have worked at backends, that's how they think. 00:20:41.160 --> 00:20:45.540 But for embedded systems, it might be more like your PC is talking to 00:20:45.630 --> 00:20:49.440 some serial port or RS485 bridge, which then is talking to a device. 00:20:49.620 --> 00:20:52.630 So before I was talking about a client talking to Poststation, 00:20:52.650 --> 00:20:54.060 talking to the embedded device. 00:20:54.120 --> 00:20:58.050 And the cool thing about proxying is you can proxy multiple times because 00:20:58.050 --> 00:21:01.690 you don't necessarily have to know, because I said it was transparent. 00:21:01.810 --> 00:21:02.040 You can proxy multiple times. 00:21:02.040 --> 00:21:06.430 So I could proxy from my computer application to Poststation, Poststation 00:21:06.430 --> 00:21:13.820 two USB to serial port adapter firmware that is then talking to another device 00:21:13.820 --> 00:21:16.880 on the far side of that, or some wireless adapter or something like that. 00:21:16.270 --> 00:21:20.720 And both of them can be very, "Hey mush brain, I don't have to know 00:21:20.720 --> 00:21:21.370 what the entire network looks like." 00:21:21.640 --> 00:21:25.300 And so you end up with this, you know, a proxy of a proxy of a proxy of a 00:21:25.300 --> 00:21:30.800 proxy where instead of being that iconic like internet picture of every node 00:21:30.800 --> 00:21:35.085 connected to every node, you get this directed acyclic graph of networking. 00:21:35.325 --> 00:21:38.115 Where as long as you're always going downwards, you can go 00:21:38.115 --> 00:21:40.515 down until you actually hit the node you were looking for. 00:21:40.575 --> 00:21:44.515 And that node can then fire the communication back up the line and 00:21:44.515 --> 00:21:47.115 it always ends up back at the client that it was interested in talking to. 00:21:47.445 --> 00:21:51.865 And this is one of those things I did over Christmas break is I wrote a wireless 00:21:51.865 --> 00:21:55.975 protocol for devices around my house so that now I can talk from my computer 00:21:55.975 --> 00:21:59.295 to Poststation to the adapter over the wireless network to the wireless device. 00:21:59.665 --> 00:22:03.665 It can talk all the way back up to me, and I don't have to know that there 00:22:03.665 --> 00:22:07.985 were however many hops there are in that, but it all still generally works. 00:22:07.375 --> 00:22:07.825 Amanda Majorowicz: There we go. 00:22:08.055 --> 00:22:10.955 Like, don't hold me accountable. 00:22:10.955 --> 00:22:11.395 Don't hold me liable for any of this. 00:22:11.425 --> 00:22:11.725 James Munns: Yeah. 00:22:11.965 --> 00:22:15.535 But yeah, I try to not get too deep in the slides so we could 00:22:15.535 --> 00:22:17.585 actually talk about stuff. 00:22:17.585 --> 00:22:17.975 Amos Wenger: Sure. 00:22:18.065 --> 00:22:19.805 James Munns: Because there's some fun side effects to this. 00:22:19.135 --> 00:22:23.915 Can you see the other price you pay when you don't have a routing table? 00:22:23.275 --> 00:22:27.995 If proxying is like taking the envelope and putting it in another envelope to 00:22:27.995 --> 00:22:31.835 pass it on, when you end up doing this proxying multiple layers deep, instead of 00:22:31.835 --> 00:22:35.005 having a routing table, you end up having to build this stack of nested envelopes 00:22:35.005 --> 00:22:37.015 that have the address on each side. 00:22:37.070 --> 00:22:41.265 And so if you want to go to a destination that's six layers deep, 00:22:41.265 --> 00:22:43.695 you take your envelope and put it in an envelope and put it in an envelope. 00:22:43.695 --> 00:22:47.415 And put it in an envelope, which I haven't decided if I love yet. 00:22:47.520 --> 00:22:50.990 It's simpler for the devices in the middle 'cause they just take the envelope out. 00:22:50.990 --> 00:22:52.910 Do I know this person directly connected to me? 00:22:52.970 --> 00:22:53.080 Yes: pass it on. 00:22:53.260 --> 00:22:57.230 No: just throw it away or bounce it back so they don't 00:22:57.230 --> 00:22:58.400 have to keep track of routing. 00:22:58.725 --> 00:23:02.325 But if you go more than a couple hops deep, essentially you're putting 00:23:02.325 --> 00:23:04.155 like a MAC address on every layer. 00:23:04.225 --> 00:23:06.175 And so you end up paying that. 00:23:06.265 --> 00:23:10.435 But my hope is that most of these networks are fairly shallow. 00:23:10.435 --> 00:23:13.375 Like I can't think of very many use cases where you'd go more 00:23:13.375 --> 00:23:15.745 than three or four deep, but... 00:23:15.745 --> 00:23:18.175 Amos Wenger: Plus, I can't imagine the envelopes being that big, right? 00:23:18.550 --> 00:23:21.280 James Munns: Right now, well, for postcard-rpc specifically, 00:23:21.280 --> 00:23:26.050 I use eight bytes or 64 bits as like the unique IDs of devices. 00:23:26.050 --> 00:23:27.550 So I end up needing to stick that. 00:23:27.550 --> 00:23:31.520 And then one byte that says, "This is a proxy message!" in each one. 00:23:31.520 --> 00:23:35.540 So it's nine bytes on every hop, which for us doesn't sound a lot, 00:23:35.600 --> 00:23:38.690 but when you have like little tiny wireless networks or serial port 00:23:38.690 --> 00:23:40.270 networks, that adds up pretty quick. 00:23:40.270 --> 00:23:42.085 Amos Wenger: You know what you should do? 00:23:42.525 --> 00:23:45.495 You should reserve one value- you should have a niche value for "this 00:23:45.495 --> 00:23:49.605 is not a proxy message," and then you can save one byte on every message. 00:23:49.695 --> 00:23:50.265 It's not a joke. 00:23:50.265 --> 00:23:51.915 This is an actual protocol design. 00:23:51.065 --> 00:23:54.155 James Munns: So how postcard-rpc works in this case is you have 00:23:54.245 --> 00:23:56.105 messages that have unique IDs. 00:23:56.110 --> 00:23:56.230 Mm-hmm. 00:23:56.310 --> 00:23:59.985 So what I do is I hash the schemas and get the IDs and then you figure 00:23:59.985 --> 00:24:02.870 out if there's a, you know, you, I do the, perfect hashing of that. 00:24:02.890 --> 00:24:05.025 So proxying ends up just being another kind of message. 00:24:05.025 --> 00:24:08.545 So the actual header on that is just that. 00:24:08.575 --> 00:24:11.875 So that was the one byte you're kind of already paying for any kind of messages? 00:24:11.095 --> 00:24:13.345 Because in my networks I'm also talking directly to the 00:24:13.345 --> 00:24:15.235 bridge device as a real device. 00:24:15.535 --> 00:24:20.305 And also it has an end point that says, "Please pass this on to your friends on 00:24:20.305 --> 00:24:22.955 the other network," Those kind of things. 00:24:22.955 --> 00:24:26.465 So that one's free, but I still have to include the serial number on that. 00:24:26.495 --> 00:24:29.450 Although I could maybe be smart and then do a mapping of, I don't know. 00:24:29.480 --> 00:24:32.420 But then it, then it just becomes a bad routing table, I think. 00:24:32.420 --> 00:24:34.800 I have to draw the line somewhere. 00:24:34.565 --> 00:24:38.735 Amos Wenger: I was gonna ask like, did you do varint encoding, which 00:24:38.735 --> 00:24:43.985 is where even if you can technically have up to 64 bits with integer, 00:24:43.985 --> 00:24:45.175 you don't always send eight bytes. 00:24:45.175 --> 00:24:48.055 You can kind of like smaller intes take fewer bytes, but it 00:24:48.055 --> 00:24:50.255 doesn't make sense for IDs, right? 00:24:50.255 --> 00:24:52.155 'cause they're more like unique IDs, random values. 00:24:52.185 --> 00:24:54.265 James Munns: You assume that they're, yeah. 00:24:54.265 --> 00:24:55.795 You assume that they're randomly distributed. 00:24:55.185 --> 00:24:59.875 An eight byte value could technically be up to 10 bytes. 00:25:00.015 --> 00:25:03.455 You only get seven bits per byte when you use a varint. 00:25:03.475 --> 00:25:05.255 'Cause everything else in postcard is, varint. 00:25:05.275 --> 00:25:07.825 But this is specifically an array of eight bytes, just so 00:25:07.825 --> 00:25:09.505 I don't pay the varint costs. 00:25:09.685 --> 00:25:13.015 Because in many cases, if you had the top bit set just like the highest bit 00:25:13.015 --> 00:25:16.355 set in the serial number, then all of a sudden now it's the largest varint 00:25:16.375 --> 00:25:18.895 because it has the highest max value. 00:25:18.955 --> 00:25:19.135 So. 00:25:19.135 --> 00:25:19.380 Amos Wenger: Varints are easy. 00:25:19.420 --> 00:25:24.750 They're like UTF-8, but for numbers and that explains everything I think. 00:25:25.750 --> 00:25:26.160 I think we're all clear on that now. 00:25:26.220 --> 00:25:27.650 James Munns: Yeah, and it turns out they're actually really fast and this 00:25:27.650 --> 00:25:31.710 is probably just like an artifact of computers being optimized for this. 00:25:31.710 --> 00:25:34.250 Or at least on desktops, they're so memory IO bound. 00:25:34.490 --> 00:25:38.030 The cost to actually just sit there and iterate over the top bit and things like 00:25:38.030 --> 00:25:43.960 that is actually astoundingly... I tried a bunch of clever other variable sized 00:25:43.960 --> 00:25:45.670 integers other than like the classic. 00:25:45.900 --> 00:25:49.770 Varint or LEB64 that like Protobuf uses and whatever. 00:25:49.850 --> 00:25:53.970 And it was like a negligible difference, even if you were doing something. 00:25:53.000 --> 00:25:54.470 It's one of those things where you look at it, you go, "That's 00:25:54.470 --> 00:25:57.770 gotta be way faster!" Superscalar architecture punches you in the face. 00:25:57.780 --> 00:25:59.790 Every single time you make assumptions like that. 00:25:59.850 --> 00:26:00.300 Amos Wenger: Mm-hmm. 00:26:00.540 --> 00:26:00.541 Mm-hmm. 00:26:01.390 --> 00:26:03.920 James Munns: Proxying, it's good for you. 00:26:04.220 --> 00:26:04.730 Amos Wenger: All right. 00:26:13.330 --> 00:26:16.540 This episode is sponsored by Depot, the Build Acceleration platform that's on a 00:26:16.540 --> 00:26:18.790 mission to make all builds near instant. 00:26:18.850 --> 00:26:21.280 If you're tired of watching your build, building Github actions crawl like the 00:26:21.280 --> 00:26:25.060 modern day equivalent of paint drying, give depot's Github action runners a try. 00:26:25.535 --> 00:26:29.525 They're up to 10 x faster with unlimited concurrency, faster caching support for 00:26:29.525 --> 00:26:33.185 Linux, Macs, and Windows, and they plug right into other depot optimizations like 00:26:33.185 --> 00:26:37.965 accelerated container image builds and remote caching for Bazel Turborepo. 00:26:37.145 --> 00:26:40.655 Gradle and More Depot was built by developers who were tired of wasting time 00:26:40.655 --> 00:26:41.005 waiting on builds instead of shipping. 00:26:41.185 --> 00:26:46.115 It's made for teams that wanna move faster and stay focused on what actually matters. 00:26:46.285 --> 00:26:49.405 That's why companies like Post Hog use depot to cut build times from over 00:26:49.405 --> 00:26:51.175 three hours to just three minutes. 00:26:51.175 --> 00:26:53.395 Saving tens of thousands of build hours every week. 00:26:53.545 --> 00:26:57.845 Start your free seven day trial at Depot Dev and let them know we sent you.