,
11 tweets,
3 min read
Read on Twitter
1/ This question asks: "why would you want a non-random random function". This is a common thing, so I thought I'd explain it.
2/ One example is games, like NetHack or the 3D version from Blizzard known as "Diablo". In the game, you descend many layers into dungeons and fight monsters. The map for each level consisting of rooms and tunnels is laid out "randomly". 
3/ Only it's not "random". A single 32-bit random number is used to 'seed' a predictable sequence, which determines how hundreds of levels and thousands of rooms are laid out. Saving the game means only saving that one number.
4/ Consider 'masscan', a tool that scans the entire Internet. You can pause scan in the middle and then continue it later. Like NetHack, it doesn't save a list of 2 billion addresses it has left to scan when you pause it.
5/ Instead, it saves the 'seed' used to create the random sequence of IP addresses, and the current index (some number between 0 and 4-billion). All you need to resume the scan in the middle is those two numbers.
6/ (I should mention: when you scan a range of addresses, it does so in random order).
7/ So you ask "You mean you based the design of an Internet-scale port scanner on NetHack?"
Yes. Yes I did.
Yes. Yes I did.
8/ Unit test code does this a lot as well. Let's say that you are testing some complex number crunching code that processes gigabytes of input. You 'seed' that with a random number generator, that generates the data, and verify that the answer comes out to the expected value.
9/ Over time, as you maintain the code base, fixing bugs, adding features, any input with that seed should always create the same output value. So you see this "non-random random numbers" used everywhere in unit tests.
10/ Here's a screenshot of starting masscan of the entire Internet and hitting <ctrl-c> to pause it a second after it started, after it's already scanned 152 random IP addresses. As you can see, it needs to remember only the 'resume-index' and the 'seed', not which addresses.
11/ The 'seed' and 'index' are 64-bit numbers, which is why it appears to be such a large number. Yes, I get that seed from /dev/urandom, but I also xor in nanosecond-scale timestamps to make sure it's random.
