Birbla

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • The most interesting result to me is that the richer parsed representation was not necessarily the faster one. If the hot path is mostly “read from cache and serialize back to DNS,” parsing everything upfront only to serialize it again can become unnecessary work and hurt locality....
    by 9bot
  • I've run into issues with using public wifi when I override my MacBook's DNS server to 1.1.1.1 or 8.8.8.8. I believe this is because captive portals require custom resolution of the name captive.apple.com. And external DNS servers will not resolve that correctly to the local gateway's authorization page.
    by bhouston
  • Dumb captive portals, which do still exist in some places, usually do MitM attacks on the connection, so you need some http(no-s) site that you can abuse as "yeah, this can get attacked by the WiFi" to then answer the portal.

    The right way is that there's DHCP option for the network to signal "I have a captive portal", that's been standardized for over a decade.

    … or … IDK … just stop shoving ads down people's throats just because they want WiFi.

    by deathanatos
  • That’s a Mac bug if so—it should be always using dumb udp/53 for captive detection, not some fancy DoH thing.
    by brians
  • AFAIK (at least it worked like that some 10 years ago) the captive portal just intercepts the HTTP page load and inserts its own content (most often a 302). So it just has to be a http web page. Firefox uses http://detectportal.firefox.com/canonical.html

    Relevant support page, though light in details: https://support.mozilla.org/en-US/kb/captive-portal

    Edit: ah, yes, DNS can be hijacked too (requires intercepting outgoing traffic on port 53 therefore incompatible with DoH), that may require fewer computing resources. Still need http otherwise the server cannot use the correct cert chain.

    Edit 2: Wikipedia says both methods are used: https://en.wikipedia.org/wiki/Captive_portal and also mentions RFC 8910. I suspected something like that existed, hence my initial disclaimer.

    My point was: that domain is not treated any differently from other domains.

    by MayeulC
  • It's weird that it took so long for these trivial optimizations but it might just be that they were working on optimizing other stuff.
    by 0xAstro
  • this applies to more than DNS caches. In 1998 I mailed Microsoft a proposal to replace search engine crawlers with a push-based filesystem monitor (detect change → extract → compress → push to index). Got a 5-line rejection letter. They built the same thing 20 years later as IndexNow. Full story with the original letter: https://dev.to/andrew_vl/in-1998-i-proposed-push-based-searc...
    by sergq
  • General theme: A programming language's native in-memory object format is typically optimized for random access, uniformity, and mutability (fields at fixed offsets, etc). Serialization formats for network or disk tend to be designed explicitly to be more compact. But you can design your own in-memory representation too, with the properties you need.
    by edflsafoiewq
  • That’s the old school of thought. These days, designers of newer serialization formats realize that designing a more compact format doesn’t really buy much on modern CPUs and modern networks. See for example Cap’n Proto (whose inventor, kentonv, also works at Cloudflare) and flatbuffers.
    by kccqzy
  • Funny thing about cloudflare. I have a dns warming script that uses their top 1k or 10k addresses. Then when my master starts up it warms the entire cache. Everything else uses memcache so the cluster is nice and toasty. As far as I can tell no one else releases domain statistics like them.
    by BikiniPrince
  • Not sure what they use to hold the cache key and entry. If a hashmap is used, then a radix tree (adaptive radix tree) would be better in saving memory space. Most of content of the qname field of the CacheKey is hostname, like www.site.com. The reverse version com.site.www fits nicely in navigation path of a radix tree. The common prefixes like "com." are shared and compressed in the parent nodes of the tree.

    Even a BTree with compressed prefix keys can save space in the qname.

    by ww520
  • At this scale, moving from one pointer chase to multiple is almost certainly a huge loss, even if radix tree would save a lot of memory.
    by Tuna-Fish
  • Exactly: https://github.com/pytries/marisa-trie
    by vismit2000
  • One of my proudest professional moments was when me and three others managed to reduce memory load of the game Wavetale from 20+GiB to under 3GiB so we could port it to Nintendo Switch.

    The 100 TiB number almost gives me vertigo. Though in this context it was "just" 50%

    by Agentlien
  • I'd love to hear what was taking up that 17GiB if you can share, even if it is commonly optimized things like packing, still fun to hear about
    by adzm
  • This reminds me how you can save a bunch of bytes just by making sure your structs are aligned. In go for example:

      type Wasteful struct {
    a int16
    b int
    c byte
  }

  type Aligned struct {
    b int
    a int16
    c byte
  }
    Will have sizes of 24bytes and 16bytes (on a 64bit system). Same data 8bytes more. If you are storing millions of those objects, then it adds up.
    by grep_it
  • Why this is not done automatically by the compiler? That seems something quite easy to calculate to me.
    by jordiburgos
  • Rust does that automatically unless you switch to the C layout.

    In langages that don’t there’s a tension between memory use and human readability / consistency of the layout.

    There are also other domains which can be affected e.g. databases, it’s a concern / issue when using postgres for instance as it uses aligned columns and stores them in schema order.

    by masklinn
  • These seem like some fairly standard approaches for reducing memory usage. I can't help to think that the approach of joining several distinct list into a single one in some way undercuts Rust's safety guarantees.

    If you previous had three distinct Vec objects, then Rust would guarantee that you can't index out of bounds. If you now put all those objects into a single Vec and rely on offsets, then you now open the door to indexing out of range of these sub-slices without any panics.

    It's a minor point, and it doesn't really invalidate the optimization, but I'm surprised the article didn't mention it.

    by vinkelhake
  • Tools exist to serve us, not the other way around.
    by FpUser
  • > I can't help to think that the approach of joining several distinct list into a single one in some way undercuts Rust's safety guarantees.

    Not really. You just need to make the underlying fields private and provide methods to get slices to the data you need.

    by afdbcreid
  • You can make a wrapper type that abstracts the offset lookup logic with a safe interface. If it's a transparent struct then rust will compile it away into nothing but you still get the abstraction in your code.
    by NIckGeek
  • It's the exact thing Rust is made to protect against, on a more local scale. Every memory corruption bug is just an out-of-bounds index that wasn't protected against.
    by pocksuppet
  • you could always do a .get into the vector and handle the error, it doesn't necessarily need to panic.

    Thank being said in this case it should be impossible to index out of bounds so maybe a panic is warented.

    by vsgherzi
  • I think it’s more of a time vs code tradeoff, if done properly.

    For example in the Vec case, you could theoretically build an alternative which encodes the “three sections” property internally, and ensures correctness at construction time for the pointers. Not as completely safe as a Vec, but you can still get similar benefits for the “business logic”.

    But I agree, just having a custom structure that does not provide a safe wrapper around this would be sacrificing standard guarantees.

    by ratorx
  • With my own MaraDNS, I aggressively optimized the memory usage of blacklist entries by having a single really big malloc() to allocate the memory for the entries, then traversing that memory block for potentially blacklisted entries.

    When I was using one malloc() per entry, a large blacklist took up 237 megabytes of memory. The same blacklist, once optimized to be loaded with a single malloc() call, only took up 9.5 megabytes of memory.

    https://samboy.github.io/blog/entries/MaraDNS.html#BlogEntry...

    by strenholme
  • Why do I always find interesting new Twitter accounts just as the person is leaving :)
    by badatnames
  • Might be of interest:

    - TigerBeetle: A database without dynamic memory allocation, https://news.ycombinator.com/item?id=33192288 (2022).

    - Succinct Data Structures: Cramming 80,000 words into a Javascript file, https://news.ycombinator.com/item?id=2348619 (2011).

    by ignoramous
  • This is why system programming still matters.

    Looks like they're missing the obvious optimisation of putting the record data right after the CacheEntry members instead of allocating memory separately though. But that might just be me as a C-programmer talking and not be all that easy in Rust.

    by irdc
  • less ergonomic, but still totally doable
    by cobalt