3 ms·
Latency due to head-of-line blocking is a big issue with TCP. Any packet loss causes a backup of all other data while waiting for retransmit. Window negotiation
by paulsutter 3y ago
Latency due to head-of-line blocking is a big issue with TCP. Any packet loss causes a backup of all other data while waiting for retransmit. Window negotiation would make your control spotty because you’d be layering two different/incompatible flow mechanisms
> But why bother with UDP? Why can’t you do this with a TCP connection? Just measure the time deltas and throttle yourself if it spikes, right? Good question, and I don’t have a good answer.
- touisteur 3y agoWell if you're not using no-delay you are not really on control of the actual TCP sending rate, the kernel might assemble or split the buffer you're send()ing.
- withinboredom 3y agoWhich might be a good thing if you're sending a bunch of tiny little packets to a consumer on wifi (cough lots of golang projects) instead of assembling/splitting the buffer yourself.
- paulsutter 3y agoHead-of-line blocking has nothing to do with Nagle (default delay behavior, that is disabled by every single TCP application I have ever seen). Head of line blocking is stochastic pile-up of data that happens during packet loss
- touisteur 3y agoI was answering the specific question of GP: "Why can’t you do this with a TCP connection? Just measure the time deltas and throttle yourself if it spikes, right" which wasn't limited to head of line blocking but more precise handling of transfer-rate of packets. Still, TCP is controlled by receiver so if you have a have on both hides you might be able to do what GP suggests, but you'd still pay the jitter of sender buffer and the noise of fragmentation of your messages.