3 ms·
Well 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.
by touisteur 3y ago
Well 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.