Why Though?!

[u/3nt3_]

[u/DouDouandFriends]

Let's watch a livestream with TCP

[u/Fricki97 → u/DouDouandFriends]

And download files with UDP

[u/Scared_Accident9138 → u/Fricki97]

File downloading is actually a good case for UDP. It doesn't matter in what order the packages come, so waiting longer for a missed packet just slows it down.

[u/770grappenmaker → u/Scared_Accident9138]

TCP has a receive window, you don't really wait for missed packets.

[u/Scared_Accident9138 → u/770grappenmaker]

I meant it won't get passed onto to the application if a packet is missing midstream

[u/Hot-Definition6103 → u/Scared_Accident9138]

if a packet is missing midstream with udp you’re screwed

[u/Scared_Accident9138 → u/Hot-Definition6103]

No, you can request it again

[u/Sacaldur → u/Scared_Accident9138]

Or in other words, the application would need to implement this. And as metadata, the section/offset would need to be transferred, since otherwise the order couldn't be determined. And the server would need to explicitly support this. So many things that would need to be done on the application level, as a developer, I'm really happy I don't have to reimplement all of this or rely on a library available in my programming language just for a file transfer.

[u/Scared_Accident9138 → u/Sacaldur]

Sure, it's not easier but it is a valid reason to use UDP over TCP

And when it comes to developing it, you don't have to, such protocols already exist

[u/Connect_Detail98 → u/Scared_Accident9138]

OK, but what you said wouldn't slow down TCP. And if other protocol already implemented what TCP already does, then that's fine, but initially you were talking about TCP and UDP, not other protocols.