TCP is shit

If you're so lazy that you have to rely on a lower level protocol for reliability, rather than implementing your own reliability features at the application layer, it's time to stop programming.

>>39
congestion control is for pussies. just buy better internet.

TCP splits messages. reciever can recieve only half of the message at the application level right? if it is big enough.

if yes it sucks.

>>41

Oh cool, it's the 80s again?! Fuck TCP here we come congestion collapse!

>>42

There's no such thing as a "message" in TCP. Towards applications TCP provides reliable byte stream, internally it uses segments, and below packets.

>>44
meaning it is shit.

>>42
It does not provide framing, and that's an endless cause of bugs in shittily written software. Surely it's not that difficult to prepend the length to each message, and add 10 lines of code to handle the reception?

Well, I guess it would be difficult for most of today's "programmers". It'd make a nice interview question.

>>45

Meaning you have no understanding of networking protocols and should stay away from them.

>>47
I just can't understand necessity of TCP. If you need congestion control, message ordering etc it could be easily implemented in application level. any respectable language would have libraries for such task.

I am not happy with the idea of "streams" instead of "datagrams" either. It forces you to check size of input buffer at application level to check if size is correct. It shouldn't be programmer tasks.

>>48
I just can't understand necessity of TCP. If you need congestion control, message ordering etc it could be easily implemented in application level.
You must be trolling. Nobody could possibly be that stupid.

>>48

Go ahead and try to do it at application level. I guarantee you'll quickly see why it's not as simple as you think. And we do have "libraries" for congestion control, message ordering and reliable delivery, it's called TCP and it's implemented in the kernel because that's the most efficient way to do it.

Reliable byte stream and datagram abstractions are for different things, it's not a question of "liking" one, it's a question of picking the right one for the job. You do VoIP or streaming media? UDP (or more likely RTP on top of UDP) is likely the correct choice. You want to transfer files? You want TCP (possibly FTP over TCP). Want to build a generic application protocol X? You want TCP 99% of the time.

Don't like the stream abstraction? Fine, use a message based protocol that gives you framing, like HTTP for example. Guess what they're implemented on top of? Yes, TCP.

And how is checking input buffer size not a programmer task? Who should do it, fairies? What you probably mean is that writing distributed applications, at least the networking parts, is not for generic application programmers. Which I completely agree, you want to pick a protocol that gives you what you need and then you want to get an implementation of said protocol with a nice and simple API by someone who actually knows how to write networking code.

>>50
You're wasting your time. Read >>49.

>>50
Who should do it, fairies?
Fairy-Oriented Programming is the future.

>>50

And we do have "libraries" for congestion control, message ordering and reliable delivery, it's called TCP and it's implemented in the kernel because that's the most efficient way to do it.

I stopped reading after this sentence because I realized that you're the same moron that doesn't have the mental capacity to become more than a general laborer in life.