[MorganGallant]

The really interesting idea here is that once you change the frame of reference, or start from a different technical basis, features like Taildrop become incredibly easy to build and design - it seems like it almost built itself. It seems like the same goes for interfaces or platforms… once you have a computer in your pocket capable of 11T operations per second, you get a lot of stuff “for free” right out of the box.

[eru]

That reminds me of https://franklinchen.com/blog/2011/12/08/revisiting-knuth-an...

Basically, Knuth was writing a beautiful but excessively low level program. His challenger wrote a dozen lines of shell-script.

[svat]

Not "his challenger"; it was not a contest. It would be more proper to say "his reviewer, the inventor of Unix pipes, using the review column to advertise UNIX®". See a previous discussion here: https://news.ycombinator.com/item?id=22406070

Incidentally, a couple of days after that thread, the current fastest submissions (which, like Knuth, all use tries) were posted at the question https://codegolf.stackexchange.com/questions/188133/bentleys... mentioned in a sibling comment. (AFAICT that comment should say "200 times faster", not "30 times faster", but anyway in light of the original context it's not meaningful to compare the two approaches either for efficiency or ease of implementation or anything else.)

[eru]

Thanks for the extra context!

Yes, my 'challenger' didn't mean to imply a formal contest.

[nindalf]

Codegolf page with solutions up to 30 times faster than the McIlroy shell script solution - https://codegolf.stackexchange.com/questions/188133/bentleys...

[eru]

Interesting, that they can only get 30 times faster with modern technology and more complications.

I guess, if you really wanted to solve this fast, you'd massively parallelize.

In any case, this was more about easy of implementation than about runtime speed.

[bsder]

Sure, once you "Bust a NAT" sharing is stupidly simple.

"Bust a NAT" is anything but easy, however.

[bookofsand]

Indeed. For those that started scratching their heads 'this is impossible', this deep dive from the Tailscale blog will be informative. Perhaps even entertaining, the birthday paradox may have a hand in it.

https://tailscale.com/blog/how-nat-traversal-works

[iso1210]

However in situations where you have say a Juniper SRX scrambling both source and destination ports on both sides of your nat, the birthday intersect is 2^32 rather than 2^16.

With a Cisco ASA or Fortigate which tends to keep the same source port where possible you'll converge far more quickly. When there's a central server to help it's even quicker and most of the time will just work.

(sometimes it's not possible to keep the same port when source-natting -- with two devices from 192.168.0.1:9000 -> 1.1.1.1:53 and 192.168.0.2:9000 -> 1.1.1.1:53, the second will have to have a mapping to non-:9000 source IP, but in my experience, Cisco, Fortigate and Mikrotik (thus linux) all support the "only change if needed" option)