We've talked about this before and it's not really possible. For one thing, the OS lies, it'll hold a buffer around of data is has/hasn't actually sent out yet, on OS X it's half a meg.
What pipe does now is ensures that both ends, the reader and the stream being written to, are both going at their best speed (not going to fast for the writer and spooling in to memory). If you want, you can write some pretty simple logic that listens to data, checks the length, and calls pause() for some period of time to taper the transfer at a constant rate. It's not terribly efficient and there is no guarantee that the OS is not buffering data at a greater rate than you are pushing it, but it's the best you can do. I don't think we'll ever put something like this directly in to core. -Mikeal On Feb 3, 2012, at February 3, 20122:09 AM, Cosmere wrote: > Hello, > > When piping data from one stream to another it is sometimes useful to > be able to accomplish the data transfer at a specified rate. This is > useful for at least 2 reasons: > 1) To prevent the transfer from consuming more than a certain amount > of system resources > 2) Because the data has an inherent rate (constant or variable) > > Do you think it would be feasible to support such a feature in the > stream.pipe method? > > Thanks
