This is him ranting about the unfounded, negative and incorrect feedback he's been receiving about them from people who are willfully ignorant about networking. He could or should have replied with less attitude and more facts, though. I understood what and why he's saying what he is, but I didn't enjoy the negativity either.
I can see his frustration: ignorance frequently has the loudest voice - especially on The Internet.
* "TCP is good enough for Minecraft, it's good enough for you." Blissfully ignores the numerous networking-related bugs that have been present in Minecraft for years.
* "Premature optimization is the root of all evil." Blissfully ignores the remainder of Knuth's quote.
* "UDP is too complex, you won't get it right." Blissfully ignores any and all challenges, never improving their ability.
* "Internet is fast enough." No, it isn't.[1]
* Learns any or all of the above from someone else and believes it because it requires less effort.
Here's someone who has been putting out top-notch content on how to solve the hard problems out of nothing else but for the common good: educating people on how to make games. What do people do? Challenge those facts with superstition and unbelievable ignorance. He's got all reasons to be frustrated, I didn't even write those beautiful articles and I'm frustrated.
He's been putting in so much effort and when people blissfully ignore it, yeah, it's going to be frustrating.
Let him have his rant - at least he's not throwing the towel in. Everyone has their bad days.
[1]: http://www.statista.com/statistics/381388/asia-average-inter...
A lot of folks conflate personal insults ("you, ggambetta, are clearly a dunderhead when it comes to reading comments") with general sentiments about a group or abstract population ("Hacker News posters tend to be overly sensitive to the point of being crybabies").
A great deal of the flavor and comedy in writing, especially pieces that are self-identified rants, are not from personal insults but instead from hyperbolic and sometime vitriolic statements about an abstract other.
My only real complaint is that he's addressing a particular person here. In his shoes I would have anonymized the source of the text and maybe blended material from a few different people. I'd rather the individual didn't accidentally recognize their words.
Other than that, I think I'm ok with people making exasperated rants. For those of us who actually understand the topic or have experience of teaching, I think a rant like this can at least be funny, and often can be cathartic. One shouldn't howl at the noobs, but howling at the moon seems fine by me.
I think it's also helpful for novices to see the occasional bile-dump like this. The question comes across to me as kinda lazy. The querent never really took the time to understand the core technologies and instead just spent a few months implementing broken stuff. But rather than think it through, he just waves away an expert answer as "kind of silly". A piece like this can help novices see how frustrating and self-defeating that kind of laziness is. I know I've benefited from seeing others get roasted for mistakes I could well have made.
https://news.ycombinator.com/item?id=10212003
Please take the time to read and digest nickpsecurity's comment in its entirety before forming an opinion about it.
I taught Computer Graphics for several years, and I came across two kinds of students: uninterested, so no matter what you do they probably won't learn; and interested and trying hard but not understanding, in which case it's my responsibility as the teacher to find a way to get the idea into their heads.
In this latter case I believe asking someone who is trying (but failing) to understand what I'm saying "What the fuck is wrong with you?" doesn't lead to better understanding on their part. Yes, I promote my own work, but this is because I feel it caters to a public that is usually left out -- the absolute beginner. The kind of people who are missing a mental leap or two to get the concepts but are either ignored or essentially called idiots for not understanding.
"Yeah... Gaffer is well-known as a guide, but also kind of horribly flawed. Question 1 for networking development: Do you need everything that TCP offers? If yes, then use TCP. You're not going to outperform TCP to do what it's good at. If not, read on."
This was a gilded +20 comment in the thread despite a) being nonsense and b) having the temerity to call his advice 'horribly flawed.' He is an expert with multiple shipped AAA games. And he prefixed his rant with RANT MODE ON. Sometimes you just need the cluestick.
I took this to be something more akin to "never implement your own crypto." If everyone followed that advice there would be no crypto, so it's obviously not blanket advice.
TCP has a lot of tunable parameters where the choices are baked into it, and it assumes that extra round trips are no big deal.
Crypto does not have all that many tradeoffs. You just need expert implementation. It's dangerous and unnecessary to do it yourself.
For something that is low-bandwidth and latency-sensitive, you can take TCP and make minor adjustments and come out with something that is far better suited. Even something as dumb and easy as sending all packets twice could turn an semi-common jitter into an ultra-rare jitter.
If you could open a TCP socket with forward error correction options, and disable head-of-line blocking, then you could probably argue against custom TCP-like protocols. But that's not the world we live in.
You don't need to know that much about networking to get something that's better than TCP in this specific use case. It may be unoptimized and terrible but your goal is latency. Just pretend that 5% of packets will get lost and do something to compensate, and you beat TCP on imperfect networks, even as a novice.
WebRTC went for UDP-encapsulated SCTP in order to get a transport without HOL blocking. I'd look into that or an existing UDP game net transport (like Enet) first.
https://packetzoom.com/blog/lessons-learned-tcp-slow-start-d...
http://gafferongames.com/networking-for-game-programmers/
Very first link explained some of what Reddit poster asked with others covering how to solve the problem and why each method was used. Reading that person's post shows he or she took a casual glance at Part 4, didn't attempt to read rest, drew conclusions, then smeared same article on Reddit, then pretended to know what he or she was talking about on advanced aspects, and then asked some questions. This is the kind of behavior that makes the Internet drop verbal bombs on people as punishment and to deter future instances of laziness and arrogance.
So, when seeing this, the writer has several choices: reward the behavior by rewriting their articles points in new comment for just that lazy person w/ specific references to things he or she ignored; link back to original w/ guidance on specific parts he or she ignored; blast him or her for being a lazy idiot who writes criticisms of stuff he or she doesn't even read. I think the latter is an entirely valid strategy in such a situation. It has the side benefit of preparing the person for the fact that the Internet will drop bombs on them when they display laziness, ignorance, and sense of authority at the same time. Hopefully the deterrent effect kicks in with the poster reading the next article and its links first. And only then questioning or criticizing part of it.
Less likely to get rants that way from that writer, other writers, FOSS projects, and anyone else that doesn't tolerate such bad behavior. You're much more patient than most. Nothing wrong with that either. Let's just differentiate between people making solid attempt to learn and people like this poster. Nobody's insulting the former. If they did, I'd totally agree with you. Far as this poster, I'd have grilled him or her too.
I'm usually not bothered by insults or harsh language, so perhaps we're viewing this post through different lenses.
https://news.ycombinator.com/item?id=10212003
I think the person didn't even read the articles but smeared them anyway. Blasting such a person is entirely justified. That the rant included useful information, too, was quite generous.
If I'm writing a chess game, I could easily just stream the text format of the games over an IRC channel. Many things, including games, don't necessarily need high bandwidth or low latency over consistency.
But the attitude is definitely not warranted.
This one is just a frustrated vent at people who don't understand the difference between TCP/UDP, don't make the effort to learn about it, but feel the need to espouse about it.
--
As an aside: floodyberry, you've been hell-banned for a few years now. Might wanna mail the mods.
I emailed the mods and they told me they never banned me and that it must've been a technical glitch.
"I swear you guys are like the fucking climate change deniers of network programming."
I appreciate the sentiment in context.
It seems one would need some way of synchronizing clocks (or measuring the lag between server and client). Do you know if there is a standard way of accomplishing this?
Synchronizing clocks is one of the difficult problems in distributed computing.
Games tend to avoid doing proper synchronization of clocks by working in discrete time steps (frames). Because games run at 15-60 frames per second (a bit more for simulators), you can get away with synchronizing the clocks to +/- a few frames, ie. an accuracy of tens of milliseconds is good enough to provide a perception of real time.
In other words: game time is measured with an unsigned integer that tells how many time steps have elapsed since the game started.
I guess modern AAA games synchronize their clocks with an algorithm similar to what NTP is using. We're still talking about discrete time steps, though, so there's some tolerance for a little clock mismatch.
Roughly speaking, for prediction (to lessen the effect of perceived lag), the server could predict that I was moving forward up to the last packet received, so I'm probably still going to be moving forward. It can then use the predicted values in all calculations until it receives an actual packet informing it what actually happened (at which point it will need to decide how to handle possibly conflicting information, which is handled the same as below).
For unrolling, if you have for example a 50ms ping and I 100ms; then at T+51ms you tell the server that you killed me, but I do the same at T+100ms - effectively compensating for the 50ms of lag difference between us you should die since I killed you 1ms before you killed me. BUT now it really depends on the server choices, do you kill me because your message got there first (old-school FPS); or does the server wait for my info since I'm involved in the action and then retroactively adjust you? Worse, since the server only gets my info on T+100 you will at best only get it at T+150, meaning that you will perceive 99ms of being alive (and maybe during which you killed someone else) which the server will then have to discard before killing you (some modern FPS use this scheme, you'll notice it where you peek out around a corner from safety and then go back, before suddenly being dead from an impossible shot). Also tough is the fact that it's not a single unroll, during the extra 99ms of being alive you would have still been sending packets to the server which then all have to be unrolled.