On Jun 6, 2012, at 10:24 AM, Eric H. Jung wrote: > On Tue, Jun 5, 2012 at 9:28 PM, Steve Workman <[email protected]> wrote: > >> >> Seems like rate control can be achieved through managing the size of >> SO_RCVBUF and rate-limiting calls to recv(). > > Out of curiosity, why are both needed? Why not one or the other? > I could be wrong, but with just managing calls to recv(), I'm imagining a scenario where SO_RCVBUF is large and TCP does a big download to fill it - so, even if we waited to call recv(), there could be a large burst of data downloaded at one time to fill the buffer. This would be rate-limited from the application side, but the link would/could still be bursty. That's what we want to avoid.
And the other way around, just managing the size of SO_RCVBUF: this would seem to result in more calls to recv to empty the buffer from the applications (HTTP) side. I may have missed something in Necko's socket and HTTP code, but from what I've learned it's event-driven and dumps out data from sockets to HTTP when data is present. I guess in this scenario the network *might* be less bursty, but it's still not a controlled rate of download. _______________________________________________ dev-tech-network mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-network
