The Case of the 50ms request • Hacker News Board

Re: The Case of the 50ms request

#51

Post by rkachowski » Thu, May 06, 2021, 11:15 AM UTC

fmajid wrote: post #44

I got it straight away, but I have a telecoms engineering and networking background. This just goes to show how poorly networking is taught in most courses (as are databases), and specially in boot camps. Self-taught programmers are also very unlikely to be exposed to this kind of topic. One thing that was not offered as an option was to use a packet analyzer like tcpdump or Wireshark, even though that is the most re…

If you're talking about the game, then there is the option to use tcpdump directly on the client.

Re: The Case of the 50ms request

#52

Post by keinplan » Thu, May 06, 2021, 11:16 AM UTC

krapht wrote: post #36

keinplan wrote: post #34

Earlier quoted context omitted.

Thats what cookies are for.

What's with all the griping going on regarding javascript? Twine is made for these "choose your own adventure" type games, and it's faster to use it than handcode everything while serializing all your app state to a cookie. What's next, a bunch of complaining that electron apps are slow? That people are writing video games in managed languages?

I also think that Twine/Client-Side-JS isn't the worst choice here. It takes unnecessary load from the server and is easy to use, at least for the one creating the game.

It's just so frustrating to watch how having loads of Javascript on websites that absolutely don't need it has been normalized. I don't think people should be blamed for using Javascript (or Electron, .NET, whatever), especially for hobby projects. But I also think users shouldn't be silent about it, especially since there are young developers who actually don't know software could be better. It's just such a massive waste of resources and breaks accesibility way to often.

Re: The Case of the 50ms request

#53

Post by lbriner » Thu, May 06, 2021, 11:23 AM UTC

The interesting thing for me is that I would suspect most devs including myself would assume that if the request takes 50ms, that's how long it takes (because networks!).

I wonder how many of us are able to judge how long something should take? Not me, except anecdotally.

Re: The Case of the 50ms request

#54

Post by keinplan » Thu, May 06, 2021, 11:27 AM UTC

noahtallen wrote: post #46

keinplan wrote: post #39

Earlier quoted context omitted.

> Just wish I can only give authorization to certain JS api. This is already implemented in any browser I know, but for some reason it is available only to some functionality (microphone, camera etc.) but not for eg. Ajax, Cross-Origin Things, Websockets, Canvas2D, WebGL etc. Also before executing any Javascript browsers should ask if you want this website to execute (potentially malicious) code on your computer!

JS is pretty well sandboxed — are there any examples of websites doing anything outside of their own JS context?

Remote-code-execution as a feature just isn't a good idea. Sandboxes can (and Murphy's Law says they will) be broken out of.

There are many documented browser-exploits and basically all newer ones that are actually a danger to users involve Javascript. It's also not reasonable to assume that people only visit trusted sites.

Re: The Case of the 50ms request

#55

Post by joshspankit » Thu, May 06, 2021, 11:28 AM UTC

barrkel wrote: post #27

gizmo wrote: post #22

Pretty fun puzzle, but this kind of debugging is alien to me. Without going into too much detail, it's pretty easy to see something suspect is going on, and this hunch can be easily tested. This debugging tour takes you to strace, wireshark, all sorts of other low level debugging techniques, when really all you had to do was simulate the client with curl -d and the problem would have been pretty obvious. And in this…

That's the first thing I wanted to do after seeing the JS; since it was a simple request / response, check to see if it's a problem with the client vs the server by replacing the client with a known good piece of code. This effectively bisects the search space without first diving into low-level details.

Exactly. If anyone has ever seen The Price Is Right, this is the optimal strategy for the “higher / lower” game: cut the options in half each time.

Re: The Case of the 50ms request

#56

Post by joshspankit » Thu, May 06, 2021, 11:30 AM UTC

dbt00 wrote: post #3

noodlesUK wrote: post #2

As requested by the commenter below (now I want spoiler tags): SPOILER FOR THE GAME I’ve seen TCP_NODELAY all over the place before, but never known why. This was a fun way to find out.

hackernews feature request: spoiler tags. :)

With auto rot-13

Re: The Case of the 50ms request

#57

Post by nevada_scout » Thu, May 06, 2021, 11:35 AM UTC

joshspankit wrote: post #55

barrkel wrote: post #27

Earlier quoted context omitted.

That's the first thing I wanted to do after seeing the JS; since it was a simple request / response, check to see if it's a problem with the client vs the server by replacing the client with a known good piece of code. This effectively bisects the search space without first diving into low-level details.

Exactly. If anyone has ever seen The Price Is Right, this is the optimal strategy for the “higher / lower” game: cut the options in half each time.

Also known as: Binary Search

Re: The Case of the 50ms request

#58

Post by eddyg » Thu, May 06, 2021, 11:36 AM UTC

CaliforniaKarl wrote: post #10

A comment from the inventor of Nagle’s algorithm: https://news.ycombinator.com/item?id=9050645 (tl;dr Try turning off delayed ACK first, especially if you can’t update the code.)

Thanks for pointing out this comment! Setting TCP_NODELAY seems to be the go-to / default solution for some reason (cargo-culting? not understanding the interaction with Delayed ACKs?) when there are times when Nagle’s algorithm could probably help.

Re: The Case of the 50ms request

#59

Post by [deleted] » Thu, May 06, 2021, 11:52 AM UTC

fmajid wrote: post #44

I got it straight away, but I have a telecoms engineering and networking background. This just goes to show how poorly networking is taught in most courses (as are databases), and specially in boot camps. Self-taught programmers are also very unlikely to be exposed to this kind of topic. One thing that was not offered as an option was to use a packet analyzer like tcpdump or Wireshark, even though that is the most re…

[deleted]

Re: The Case of the 50ms request

#60

Post by amalcon » Thu, May 06, 2021, 11:58 AM UTC

nickkell wrote: post #37

Really nice game/tutorial. The best job interview I ever had was framed like this. The interviewer told me there was a bug in the system and had a stack of pages he'd printed out that would provide successive clues as to what caused it. I could ask them questions, in effect using the interviewer as a search engine/debugger. It was the closest an interview has ever come to simulating the day-to-day of a web developer.

I've said it before and will say it again: One code review or debugging session gives an interviewer more actionable information than an effectively unbounded number of logic puzzles.