4 ms·
> Say, you want to design a protocol with reliable delivery and/or loss detection. You will then have ACKs... > So - surprise! - you have no choice but to desi
by exDM69 14y ago
> Say, you want to design a protocol with reliable delivery and/or loss detection. You will then have ACKs...
> So - surprise! - you have no choice but to design a TCP clone.
Some use cases don't really want TCP or a TCP clone, for example multi-player games might only use a semi-reliable loss detection system which has ACK's but does not attempt retransmission on failure to deliver. This works a lot better than TCP for that use case, and is not really a "TCP clone".
- xyzzy123 14y agoThe really sad thing about this though is that "the internet" no longer works for stuff which isn't TCP. I guess it does, but not for your whole target market. The lowest common denominator is users behind an NTLM proxy. Mass market products don't generally work unless they have a fallback which is "I can make it tunnel through proxies". Which is HTTP or CONNECT :( Which means no teams will do something which isn't TCP anymore, since it's not a thing they can tunnel :( Interested in counterexamples though. This is the same reason why a UDP replacement is a great idea but a waste of time for most people developing a product. This makes me sad.
- ajross 14y agoAs mentioned upthread, most multiplayer games are still UDP. And indeed, they generally don't work through proxies.
- potkor 14y agoYou have it the wrong way around. People who cordon themselves off and only leave HTTP working aren't on the Internet. They don't want non-web apps to work. Those networks deliberately rule out networked games, uTP, VoIP, IPsec, WebRTC, etc. If you want to worry about people teetering on the edge of the Internet, you should worry about people behind NAT and its prevalence to the point of people confusing NAT boxes and routers... (Re your last sentence, it's not a UDP replacement, see other comments.)