5 ms·

How do you build something fast and reliable over something slow and creaky? Who knows You use TCP, which they already had. The article describes TCP as evil,

by gcp 13y ago

How do you build something fast and reliable over something slow and creaky? Who knows You use TCP, which they already had. The article describes TCP as evil, but then they go on to reimplement TCP over UDP in a way more inefficient manner, not realizing their problems with TCP were problems with the internet. They'll hardly have been the first ones to do so, either.

zura 13y ago
There also was a quite interesting protocol T/TCP - which was something between TCP and UDP.
TheZenPsycho 13y ago
so how would you have solved it? your explanation here is pretty unsatisfying since they did use TCP, and it didn't work.
tlarkworthy 13y ago
No. They implemented forward error correction, which is a proper thing not supported by TCP.
- waps 13y ago
  The article even contains an explanation why TCP does not, and NEVER should, include forward error correction : > Our simple re-sending mechanism just didn’t perform well enough under these conditions. It was quite common for a re-sent packet to be dropped, and we saw several cases where the original packet and 4 or 5 re-sends of that packet would all be dropped. We were re-sending so many packets, we were starting to exceed the bandwidth of the modem, and then the latency would start to climb, and all hell would break loose. (then they implemented a -very bad- form of forward error correction in their packets to almost never need retransmissions) This effectively ignores available bandwidth, and it worked because they were only using tiny amounts of bandwidth, so cheating helped them in this case, without ill effects. It is a dangerous game however. The problem is one of unfairness. If you implement your connections with forward error correction you will have an advantage over others, as you will not follow congestion signals while others do. And then this happens : http://en.wikipedia.org/wiki/Congestive_collapse#Congestive_collapse http://en.wikipedia.org/wiki/Congestive_collapse#Congestive_... TLDR: massive traffic on nearly every link in the network. Effective throughput almost nonexistent. You know, like being stuck on comcast.
  - tlarkworthy 13y ago
    I am not suggesting Forward Error correction is a good idea on TCP. They put UDP and forward error correction together which is a good idea (see video/audio streaming over internet). The parent seemed to think they had reimplemented TCP badly, which they didn't, they implemented quite a different protocol which utilised forward error correction which was a good idea and something they would not have been able to do by building on vanilla TCP. So their prototcol probably ended up messier than it should of been but they were pioneers fixing problems as they cropped up so that's understandable.
exDM69 13y ago
> The article describes TCP as evil, but then they go on to reimplement TCP over UDP in a way more inefficient manner, not realizing their problems with TCP were problems with the internet. Almost every real-time game out there "re-implements" parts of TCP over UDP because the mechanisms that TCP use are unsuitable for real time communication. If a packet goes lost over a 150 ms latency (something modern game engines manage gracefully), the server will receive a resent packet that contains information from 450 ms ago. Additionally a packet going lost with TCP will inhibit the delivery of successfully received packets that were sent after the one gone missing. Re-sending an old packet (like TCP does) is worse than not receiving the packet at all in multi player gaming. You do need (semi-) reliable delivery, connection management and flow control over UDP but implemented differently than TCP. When a packet goes lost, you send the up-to-date information instead, not what was relevant 300 ms ago. TCP is a wonderful protocol but absolutely useless for multi player gaming. Everyone who has been writing netcode for real-time games (there are exceptions like RTS, MMORPG, etc) knows that.
- louiz 13y ago
  I think “real-time” does not mean what you think it means. I’ve read a lot of things like “TCP is not suitable for real-time online games”, in this thread, where the author of this sentence excludes RTS, MMORPG, etc. As if these were not real-time games. According to http://en.wikipedia.org/wiki/Real-time_game#Real-time http://en.wikipedia.org/wiki/Real-time_game#Real-time (and also the fact the RTS means real-time strategy), any game that is not turn based is a real-time game. It’s not just you, but I had to choose one of the posts in this thread for my response. Saying “TCP is a wonderful protocol but absolutely useless for multi player gaming” is just plain wrong. A lot of online, real-time games are using TCP. Saying that TCP is useless for multi player gaming is really misleading and I’m tired of reading this. There are a lot of valid reason to choose TCP over UDP (for example the fact that your game doesn’t require any round-trip to be shorter than, say, 500ms, because that’s how the engine works). Of course, TCP would not really be suitable for an FPS like quake, but that’s only one case of real-time game, there are a lot of different kind of games, for which TCP is the best choice.
  - exDM69 13y ago

by gcp 13y ago

zura 13y ago

There also was a quite interesting protocol T/TCP - which was something between TCP and UDP.

TheZenPsycho 13y ago

so how would you have solved it? your explanation here is pretty unsatisfying since they did use TCP, and it didn't work.

tlarkworthy 13y ago

No. They implemented forward error correction, which is a proper thing not supported by TCP.

waps 13y ago
The article even contains an explanation why TCP does not, and NEVER should, include forward error correction : > Our simple re-sending mechanism just didn’t perform well enough under these conditions. It was quite common for a re-sent packet to be dropped, and we saw several cases where the original packet and 4 or 5 re-sends of that packet would all be dropped. We were re-sending so many packets, we were starting to exceed the bandwidth of the modem, and then the latency would start to climb, and all hell would break loose. (then they implemented a -very bad- form of forward error correction in their packets to almost never need retransmissions) This effectively ignores available bandwidth, and it worked because they were only using tiny amounts of bandwidth, so cheating helped them in this case, without ill effects. It is a dangerous game however. The problem is one of unfairness. If you implement your connections with forward error correction you will have an advantage over others, as you will not follow congestion signals while others do. And then this happens : http://en.wikipedia.org/wiki/Congestive_collapse#Congestive_collapse http://en.wikipedia.org/wiki/Congestive_collapse#Congestive_... TLDR: massive traffic on nearly every link in the network. Effective throughput almost nonexistent. You know, like being stuck on comcast.
- tlarkworthy 13y ago
  I am not suggesting Forward Error correction is a good idea on TCP. They put UDP and forward error correction together which is a good idea (see video/audio streaming over internet). The parent seemed to think they had reimplemented TCP badly, which they didn't, they implemented quite a different protocol which utilised forward error correction which was a good idea and something they would not have been able to do by building on vanilla TCP. So their prototcol probably ended up messier than it should of been but they were pioneers fixing problems as they cropped up so that's understandable.

exDM69 13y ago

> The article describes TCP as evil, but then they go on to reimplement TCP over UDP in a way more inefficient manner, not realizing their problems with TCP were problems with the internet. Almost every real-time game out there "re-implements" parts of TCP over UDP because the mechanisms that TCP use are unsuitable for real time communication. If a packet goes lost over a 150 ms latency (something modern game engines manage gracefully), the server will receive a resent packet that contains information from 450 ms ago. Additionally a packet going lost with TCP will inhibit the delivery of successfully received packets that were sent after the one gone missing. Re-sending an old packet (like TCP does) is worse than not receiving the packet at all in multi player gaming. You do need (semi-) reliable delivery, connection management and flow control over UDP but implemented differently than TCP. When a packet goes lost, you send the up-to-date information instead, not what was relevant 300 ms ago. TCP is a wonderful protocol but absolutely useless for multi player gaming. Everyone who has been writing netcode for real-time games (there are exceptions like RTS, MMORPG, etc) knows that.

louiz 13y ago
I think “real-time” does not mean what you think it means. I’ve read a lot of things like “TCP is not suitable for real-time online games”, in this thread, where the author of this sentence excludes RTS, MMORPG, etc. As if these were not real-time games. According to http://en.wikipedia.org/wiki/Real-time_game#Real-time http://en.wikipedia.org/wiki/Real-time_game#Real-time (and also the fact the RTS means real-time strategy), any game that is not turn based is a real-time game. It’s not just you, but I had to choose one of the posts in this thread for my response. Saying “TCP is a wonderful protocol but absolutely useless for multi player gaming” is just plain wrong. A lot of online, real-time games are using TCP. Saying that TCP is useless for multi player gaming is really misleading and I’m tired of reading this. There are a lot of valid reason to choose TCP over UDP (for example the fact that your game doesn’t require any round-trip to be shorter than, say, 500ms, because that’s how the engine works). Of course, TCP would not really be suitable for an FPS like quake, but that’s only one case of real-time game, there are a lot of different kind of games, for which TCP is the best choice.
- exDM69 13y ago