Revisiting Random Number Generation | Hacker News Reader

Revisiting Random Number Generation

swlody.dev

22 pointstodsacerdoti11 comments

Open articleView on HN

It seems like this small website was more complicated than I would have guessed and that caused most of the downtime.

1. Using a redis connection per socket as a cross thread message queue

2. Crashing the server on invalid sentry tracking header

3. No size validation on user input

It looks like a fun project but it ironic that the third party monitoring service to track downtime was your downtime.

Now I feel redis is not worth the effort over a Hashmap you write to disk/s3 every 5 minutes for hobby stuff. Ya ain’t gonna need it and if you do just install a full sql database

Thanks for actually reading and providing genuine technical feedback! I'm new to writing about my work so I appreciate you sticking through the meandering. Also didn't expect this to get posted here by a cross-post bot.

Definitely agree with your point about redis. This was explicitly a learning exercise for me to learn redis. For other hobby projects I'll keep using in-memory structures to keep things simple. For more serious projects I'll stick to postgres. One thing I did appreciate about redis though was the sorted set functionality which made it trivial to implement the top 10 page. As far as I know most SQL databases don't have an equivalent structure?

The Uuid from the request-id header was actually used internally to associate a submitted number with a pending request, so it served a double purpose along with monitoring. I probably should have realized that the header could be overridden to a non-Uuid. Using the unwrap() there surfaced the issue pretty quickly and it was a straightforward fix once it came up, but returning an 500 would have been surfaced just as easily and not caused the server to crash. I've now learned my lesson about keeping unwrap() far away from any server code when I'm writing other web applications in rust.

The lack of any sort of input validation was mostly intentional as I only expected friends to play with it and wanted to see what they would do with the ability to submit arbitrary-length strings. Once it got a bit of attention and more people started trying to break things is when it became a problem.

Mostly I just wanted to share the silly ways people managed to mess with the site once it got a modest audience between just people I knew personally, but hopefully other people can learn from my mistakes like I did!

Stoppped Reading 5 paragraphs. If the article fails to convey where it's going, why should I invest the time? Also, what are those hashtags? Completely unrelated to the actual content.

Yeah, there is a lot of space to explore regarding RNGs (e.g. short period but with a large stream space), but this isn't helpful.

Contra the title, the article has essentially nothing to do with RNGs and is instead about debugging the author's toy web game very verbosely.

A lot of the debugging ends up with "whatever, don't have time to find the cause, do X instead" which is super disappointing.

Yeah, I wouldn't encourage anyone to spend their time reading it.

Yeah the title probably should’ve been something like “revisiting my really really good random number generator” or “revisiting crowd-sourced rng” or something.

After reading the article, the tags are actually related to the content due to the user-supplied “random” number nature of the project and no restriction against users submitting non-numbers.

Having read all of it, missing the hashtags in the top, I want my 7 min back.

Tell me you didn’t rtfa without saying you didn’t… oh, wait.

Reply on news.ycombinator.com