May be better use UDP pakets?

May be it is better to use UDP pakets, it work faster, and most video streaming use UDP
Software send fonformation of file at the end, no need to confer every paket takes much longer time.

1 Like

And moreover udp can punch NAT

Youtube uses tcp though. TCP has buil-in data reliability, while if you wanted to do that on UDP, you would have to essentially re-implement TCP to get the same result.

Packets get lost all the time. So, instead of retransmiting the packet, you would rather retransmit the whole piece?

UDP is good when you do not care that the data gets a bit damaged, say, a phonecall it is preferable to lose a bit of the data (and have a “hiccup” in the conversation) than retransmit the lost packet and increase latency. However, I would not want to download a piece that is several megabytes in size multiple times hoping that this time all of the packets will arrive.

1 Like

A pure video stream could be UDP because a lost packet doesn’t impact it much. You might have lost a few frames but may not even notice that.

However, how would you determin when losing packets is acceptable (like in a pure video stream) and when it isn’t (e.g. I want to download the video file)?
You’d need an integration in the receiving end that tells the uplink on the storagenode to send the pieces over UDP instead of TCP. Makes it a lot more complex too.

1 Like

Also, it’s encrypted, some forms of encryption (CBC for example) fail if part of the stream gets corrupted.

I wouldn’t want to download my backup and find out that it was damaged, even if I backed up a video file.