Hacker News new | past | comments | ask | show | jobs | submit login

not exactly:

> If it’s used that way, it makes TCP a reliable, in-order protocol.

the key here is "in-order".




It's absolutely trivial to put a sequence number in UDP packets.

The question is whether you want the other mechanisms of TCP: handshaking, (limited) retransmission, flow control...


Never mind that most sensible streaming formats will include data in packets that allows the receiver to rebuild missing packets (up to a threshold).


A typical rtp stream will have smpte fec on top, allowing burst lost of say 20 packets, or random loss theoretically upto 5%

In the last 10 years of streaming rtp over the Internet the vast majority of failures is bursty. Reordering is more rare than you'd expect.

Looking at one sample from India to Europe over a period of 6 weeks, my 30mbit rtp stream was fine 99.998% with fec. The rest of the time that's why I dual stream, either timeshift (send the same packet again 100ms later - as I said most outages are time based), or dual path (although if the packets traverse the same router en route there are issues), or even both.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: