4 ms·
Gaffer is absolutely not saying 'What the fuck is wrong with you?' to beginners. He's saying it to the so-called experts who posted nonsense like this: "Yeah..
by camperman 11y ago
Gaffer is absolutely not saying 'What the fuck is wrong with you?' to beginners. He's saying it to the so-called experts who posted nonsense like this:
"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.
- pyre 11y ago> You're not going to outperform TCP to do what it's good at. 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.
- aavegmittal 11y agoAgreed. TCP is a great general purpose communication protocol, but using it in all situations is probably not a good idea. For eg, for a specific case of mobile networks, a custom protocol built over UDP could out perform TCP. details here: https://packetzoom.com/blog/lessons-learned-tcp-slow-start-doesnt-have-to-be-so-slow.html https://packetzoom.com/blog/lessons-learned-tcp-slow-start-d...
- Dylan16807 11y agoEven looking at it like that, it's wrong. 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.
- pyre 11y agoI was using "never implement your own crypto" as an example. I think that "never implement your own crypto" is a more important rule to follow than anything regarding TCP. On the other hand, if you don't know much about networking, trying to reimplement TCP over UDP isn't likely to gain you better performance. As with most things, there is no substitute for knowing what are doing.
- Dylan16807 11y agoI know it was an example, but the crypto saying is actually a good rule of thumb, while "don't do TCP" is a pretty bad rule of thumb. 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.
- zurn 11y agoThere's a lot of work besides performance to get right in a transport protocol though. Just getting the retransmission working like you want is a small part of the job. 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.
- Gibbon1 11y agoI think 'never implement your own crypto' really means, 'this is an area where there is no substitute for knowing what the hell you are doing. Sometimes knowing what you are doing is not hard (changing a tire), sometimes it is (cryto and networking)