Re:Is it just me or is networking really hard?
by pyre on Sunday September 13, 2015 @07:54PM
(#10213167)
I 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.
Re:Is it just me or is networking really hard?
by Dylan16807 on Sunday September 13, 2015 @09:46PM
(#10213361)
I 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.
Re:Is it just me or is networking really hard?
by zurn on Monday September 14, 2015 @12:55AM
(#10213693)
There'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.
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.