Эта статья демонстрирует эффект чтения файла и записи в PassThrough
поток и HTTP-ответ. Автор считает, что первый пункт назначения (PassThrough
) достиг максимальной отметки и «завис», что привело к неполному обслуживанию файла PNG. Он решил эту проблему, «опустошив» первый пункт назначения.
Код из его суть , который достигает максимальной отметки и приводит к неполной загрузке, показан ниже.
// Require node modules.
var http = require( "http" );
var fileSystem = require( "fs" );
var stream = require( "stream" );
// Create an instance of our http server.
var httpServer = http.createServer(
function handleRequest( request, response ) {
// Create our file-input stream.
var hankhill = fileSystem.createReadStream( "./hank-hill.png" );
// Pipe it into a simple transform stream.
// --
// NOTE: Our transform stream is not being piped into anything else. As such,
// its internal buffers MAY fill up (depending on the highWaterMark setting and
// the size of the file being streamed), creating backpressure and subsequently
// pausing the file-input stream.
hankhill.pipe( new stream.PassThrough() );
// ALSO pipe it into the response stream.
hankhill.pipe( response );
}
);
httpServer.listen( 8080 );
console.log( "Server running on port 8080" );
Мои вопросы:
- Почему
hankhill.pipe(response)
зависит от hankhill.pipe(new stream.PassThrough());
? Разве это не async
? - Даже если они
async
, я не уверен, получим ли мы поведение pub-sub. То есть, hankhill
будет рассматривать двух потребителей как подписчиков, так что доставка сообщений и порядок сохраняются. - Что, если бы у нас было два обработчика для
hankhill.on('data')
? Увидим ли мы тогда поведение pub-sub? - В целом, если конвейерные потоки потребляют с разной скоростью, каково ожидаемое поведение?