A couple bugs in this game, I wanted to SSH onto the client, took me to the server instead.
The Case of the 50ms request
21–30 of 88 posts
Re: The Case of the 50ms request
#22Pretty 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 case the more complicated debugging tools didn't even explain anything. As the last page says, the answer is kind of a leap. If you already knew about this problem curl would have solved it immediately, and if you didn't you'd still be baffled even after knowing exactly why the stack traces are the way they are.
Re: The Case of the 50ms request
#23This is great. Julia Evans has some great content in general, she's really good at explaining complex topics in an engaging and accessible way.
Re: The Case of the 50ms request
#24All due respect, this is a neat advertisment for the "storytelling" Javascript library she is using, but I learn much more by reading W R Stevens' books. There is more to TCP/IP than what one can do through Berkeley sockets. Plus reading Stevens' books does not require Javascript.
Re: The Case of the 50ms request
#25Pretty 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…
How would using curl -d make the problem obvious?
Re: The Case of the 50ms request
#26Re: The Case of the 50ms request
#27Pretty 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.
Re: The Case of the 50ms request
#28Pretty 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…
How would using curl -d make the problem obvious?
It wouldn't have split the request over separate sends.
That's what flushHeaders() is doing; it does a separate send for headers vs the body of the request.
Re: The Case of the 50ms request
#29All due respect, this is a neat advertisment for the "storytelling" Javascript library she is using, but I learn much more by reading W R Stevens' books. There is more to TCP/IP than what one can do through Berkeley sockets. Plus reading Stevens' books does not require Javascript.
Her pronouns are she/her.
Re: The Case of the 50ms request
#30Earlier quoted context omitted.
Congratulations, you have free will. Of course so does the creator of the site, and they have chosen (a choice I would make also, FYI) to construct the game this way, so you have to part ways.
> Of course so does the creator of the site, I find it very debatable that putting information on the internet does not come with associated mandatory responsibilities
I agree. There are things websites shouldn’t do - like non-consentually collecting and selling user data. Asking users to send private details over unencrypted http. Being inaccessible to screen readers. That sort of thing.
Having content that requires javascript? Eeehhhhhh. When static content like blog posts and news articles require JS it’s annoying. But for a little game like this the dev’s choice makes sense. Losing a few % of their audience is a reasonable trade in exchange for not needing to implement the whole thing twice. It’s really hard to get worked up about server side rendering for toys like this.
I suggest you pick your battles differently. This is a silly hill to die on.