In my opinion the biggest problem with TCP/IP is that TCP is a stream protocol. Everyone who uses it immediately creates some sort of scheme to divide the stream into messages. Making it a stream protocol is logically equivalent to making it a messaging protocol with messages of size 1 byte. Maybe someone somewhere uses it as a pure byte stream, but it's not very common (and can be easily simulated over a message-based protocol).
Not that I blame Vint Cerf for that.....he created it, he didn't decide which
Streams are just as trivial to implement on top of messages as the other way around. In fact, that's exactly what TCP is. But it is slightly painful to implement either one on top of the other, and since 99% of the time people want messages, logically that should have been the default.
Also, I seriously doubt (I'm giving you credit as a network programmer here) that you would have implementing one type of messages on top of another type of messages, since network programmers do it all the time. As question
Yes, TCP implements streams on top of messages, but I wouldn't call it trivial. Even though the essence of the protocol is simple, many implementers would still get it wrong.
Also, the IP message is limited in size, so if you want to implement larger messages, you'd have to split them up into smaller ones. Or, alternatively, it you want to exchange very short messages, performance will suffer. At least TCP protects you from that with the Nagle algorithm.
But, hey, if you don't like the stream protocol, you ca
Getting reliable, inorder message transfer is difficult
That's probably why it wasn't done. The beauty of TCP/IP is it's simplicity, and that's probably also why it was so successful. For most applications, the stream model works fine, so why would it be better to implement a more complex message transfer protocol instead ?
TCP is simple to use (from the view of someone doing network programming), but under the scenes it is crazy complicated to implement properly.
Fortunately you really only need someone to implement a TCP stack once (in open source) and it can be reused in a multitude of operating systems. BSD pretty much set the standard for a TCP/IP stack (TCP Reno) and everyone went from there.
Yes, it's simple and obvious, and it took years of experimentation to get the simple and obvious parts to work well. The early Internet had congestion collapse problems that TCP needed to be retuned for, and figuring out how to get slow machines to send data fast (Van Jacobson's work) took a while, and Jim Getty's Bufferbloat [wikipedia.org] work says we're not done yet.
Bram Cohen put a huge amount of incremental experimentation and testing into making Bittorrent work as well - things that are simple and obvious when you'
You had mail, but the super-user read it, and deleted it!
Biggest TCP/IP mistake (Score:1)
Not that I blame Vint Cerf for that.....he created it, he didn't decide which
Re: (Score:3)
That's not a problem, but a feature. It's trivial to make a message protocol on top of a stream, and the stream protocol is easy to implement.
Streams on top of messages, or one type of messages on top of other type of message protocol is trickier.
Re: (Score:2)
Also, I seriously doubt (I'm giving you credit as a network programmer here) that you would have implementing one type of messages on top of another type of messages, since network programmers do it all the time. As question
Re: (Score:3)
Yes, TCP implements streams on top of messages, but I wouldn't call it trivial. Even though the essence of the protocol is simple, many implementers would still get it wrong.
Also, the IP message is limited in size, so if you want to implement larger messages, you'd have to split them up into smaller ones. Or, alternatively, it you want to exchange very short messages, performance will suffer. At least TCP protects you from that with the Nagle algorithm.
But, hey, if you don't like the stream protocol, you ca
Re: (Score:2)
Even though the essence of the protocol is simple, many implementers would still get it wrong.
No. Getting reliable, inorder message transfer is difficult. Implementing a stream on top of reliable inorder messages is simple as pie.
Re:Biggest TCP/IP mistake (Score:2)
That's probably why it wasn't done. The beauty of TCP/IP is it's simplicity, and that's probably also why it was so successful. For most applications, the stream model works fine, so why would it be better to implement a more complex message transfer protocol instead ?
Re: (Score:2)
TCP is simple to use (from the view of someone doing network programming), but under the scenes it is crazy complicated to implement properly.
Fortunately you really only need someone to implement a TCP stack once (in open source) and it can be reused in a multitude of operating systems. BSD pretty much set the standard for a TCP/IP stack (TCP Reno) and everyone went from there.
Re: (Score:2)
The core of TCP, as its original RFC 793, is quite straightforward. The many later additions have made it more complicated, though.
Simplicity and Obviousness take a lot of work (Score:2)
Yes, it's simple and obvious, and it took years of experimentation to get the simple and obvious parts to work well. The early Internet had congestion collapse problems that TCP needed to be retuned for, and figuring out how to get slow machines to send data fast (Van Jacobson's work) took a while, and Jim Getty's Bufferbloat [wikipedia.org] work says we're not done yet.
Bram Cohen put a huge amount of incremental experimentation and testing into making Bittorrent work as well - things that are simple and obvious when you'