NodeJS Streams - Чтение одного потока в несколько пунктов назначения - PullRequest
0 голосов
/ 29 мая 2020

Эта статья демонстрирует эффект чтения файла и записи в 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" );

Мои вопросы:

  1. Почему hankhill.pipe(response) зависит от hankhill.pipe(new stream.PassThrough());? Разве это не async?
  2. Даже если они async, я не уверен, получим ли мы поведение pub-sub. То есть, hankhill будет рассматривать двух потребителей как подписчиков, так что доставка сообщений и порядок сохраняются.
  3. Что, если бы у нас было два обработчика для hankhill.on('data')? Увидим ли мы тогда поведение pub-sub?
  4. В целом, если конвейерные потоки потребляют с разной скоростью, каково ожидаемое поведение?
...