@@ -98,3 +98,3 @@ | ||
| <a href="https://istanbul.js.org/" target="_blank">istanbul</a> | ||
| at Sun Feb 16 2020 12:14:54 GMT+0000 (Greenwich Mean Time) | ||
| at Sat Feb 29 2020 10:06:14 GMT+0000 (Greenwich Mean Time) | ||
| </div> | ||
@@ -101,0 +101,0 @@ </div> |
+29
-1
@@ -15,2 +15,3 @@ /** | ||
| - Browser unit tests using [webpack](http://webpack.github.io/) and [nwjs](http://nwjs.io/). | ||
| - **See the [errors](#errors) section for information on why multiplexed streams error when their carrier streams closes before they do.** | ||
@@ -239,3 +240,3 @@ The API is described [here](#api). | ||
| BPMux doesn't suffer from this problem since backpressure is exerted on each | ||
| bpmux doesn't suffer from this problem since backpressure is exerted on each | ||
| stream separately. Here's the same test: | ||
@@ -291,2 +292,29 @@ | ||
| ## Errors | ||
| bpmux will emit `error` events on multiplexed streams if their underlying | ||
| (carrier) stream closes before they have closed. The error message will be one | ||
| of these two strings: | ||
| ``` | ||
| carrier stream finished before duplex finished | ||
| carrier stream ended before end message received | ||
| ``` | ||
| As this is an `error` event, you must register an event listener on multiplexed | ||
| streams [if you don't want the Node process to exit](https://nodejs.org/dist/latest-v13.x/docs/api/events.html#events_error_events). | ||
| The reasoning behind emitting `error` events on open multiplexed streams when | ||
| their carrier closes is: | ||
| - If you're reading from a stream and it hasn't ended before the carrier closes then there may be some data that you'll never receive. This is an error state. | ||
| - If you're writing to a stream and it hasn't finished before the carrier closes then your application should be informed about it straight away. If it's performing some heavy calculation, for example, then it has a chance to cancel it before writing the result to the stream. | ||
| If you do register `error` event listeners, make sure you do so for streams | ||
| you multiplex using [`multiplex()`](#bpmuxprototypemultiplexoptions) _and_ | ||
| for streams you receive using the [`handshake`](#bpmuxeventshandshakeduplex-handshake_data-delay_handshake) or [`peer_multiplex`](#bpmuxeventspeer_multiplexduplex) events. | ||
| `BPMux` objects will also re-emit any `error` events their carrier stream emits. | ||
| ## Installation | ||
@@ -293,0 +321,0 @@ |
+1
-1
| { | ||
| "name": "bpmux", | ||
| "description": "Node stream multiplexing with back-pressure on each stream", | ||
| "version": "8.0.4", | ||
| "version": "8.0.5", | ||
| "homepage": "https://github.com/davedoesdev/bpmux", | ||
@@ -6,0 +6,0 @@ "author": { |
+29
-1
@@ -14,2 +14,3 @@ # bpmux [](https://travis-ci.org/davedoesdev/bpmux) [](https://coveralls.io/r/davedoesdev/bpmux?branch=master) [](http://badge.fury.io/js/bpmux) | ||
| - Browser unit tests using [webpack](http://webpack.github.io/) and [nwjs](http://nwjs.io/). | ||
| - **See the [errors](#errors) section for information on why multiplexed streams error when their carrier streams closes before they do.** | ||
@@ -238,3 +239,3 @@ The API is described [here](#api). | ||
| [BPMux](#bpmuxcarrier-options) doesn't suffer from this problem since backpressure is exerted on each | ||
| bpmux doesn't suffer from this problem since backpressure is exerted on each | ||
| stream separately. Here's the same test: | ||
@@ -290,2 +291,29 @@ | ||
| ## Errors | ||
| bpmux will emit `error` events on multiplexed streams if their underlying | ||
| (carrier) stream closes before they have closed. The error message will be one | ||
| of these two strings: | ||
| ``` | ||
| carrier stream finished before duplex finished | ||
| carrier stream ended before end message received | ||
| ``` | ||
| As this is an `error` event, you must register an event listener on multiplexed | ||
| streams [if you don't want the Node process to exit](https://nodejs.org/dist/latest-v13.x/docs/api/events.html#events_error_events). | ||
| The reasoning behind emitting `error` events on open multiplexed streams when | ||
| their carrier closes is: | ||
| - If you're reading from a stream and it hasn't ended before the carrier closes then there may be some data that you'll never receive. This is an error state. | ||
| - If you're writing to a stream and it hasn't finished before the carrier closes then your application should be informed about it straight away. If it's performing some heavy calculation, for example, then it has a chance to cancel it before writing the result to the stream. | ||
| If you do register `error` event listeners, make sure you do so for streams | ||
| you multiplex using [`multiplex()`](#bpmuxprototypemultiplexoptions) _and_ | ||
| for streams you receive using the [`handshake`](#bpmuxeventshandshakeduplex-handshake_data-delay_handshake) or [`peer_multiplex`](#bpmuxeventspeer_multiplexduplex) events. | ||
| `BPMux` objects will also re-emit any `error` events their carrier stream emits. | ||
| ## Installation | ||
@@ -292,0 +320,0 @@ |
Sorry, the diff of this file is too big to display
Sorry, the diff of this file is not supported yet
Network access
Supply chain riskThis module accesses the network.
Found 4 instances in 1 package
Environment variable access
Supply chain riskPackage accesses environment variables, which may be a sign of credential stuffing or data theft.
Found 2 instances in 1 package
Filesystem access
Supply chain riskAccesses the file system, and could potentially read sensitive data.
Found 1 instance in 1 package
Long strings
Supply chain riskContains long string literals, which may be a sign of obfuscated or packed code.
Found 1 instance in 1 package
URL strings
Supply chain riskPackage contains fragments of external URLs or IP addresses, which the package may be accessing at runtime.
Found 1 instance in 1 package
Network access
Supply chain riskThis module accesses the network.
Found 4 instances in 1 package
Environment variable access
Supply chain riskPackage accesses environment variables, which may be a sign of credential stuffing or data theft.
Found 2 instances in 1 package
Filesystem access
Supply chain riskAccesses the file system, and could potentially read sensitive data.
Found 1 instance in 1 package
Long strings
Supply chain riskContains long string literals, which may be a sign of obfuscated or packed code.
Found 1 instance in 1 package
URL strings
Supply chain riskPackage contains fragments of external URLs or IP addresses, which the package may be accessing at runtime.
Found 1 instance in 1 package
534622
1.44%5092
0.37%544
5.43%21
-12.5%