{\ttfamily websocket-\/extensions} models the extension negotiation and processing pipeline of the Web\+Socket protocol. Between the driver parsing messages from the TCP stream and handing those messages off to the application, there may exist a stack of extensions that transform the message somehow.

In the parlance of this framework, a {\itshape session} refers to a single instance of an extension, acting on a particular socket on either the server or the client side. A session may transform messages both incoming to the application and outgoing from the application, for example the {\ttfamily permessage-\/deflate} extension compresses outgoing messages and decompresses incoming messages. Message streams in either direction are independent; that is, incoming and outgoing messages cannot be assumed to \textquotesingle{}pair up\textquotesingle{} as in a request-\/response protocol.

Asynchronous processing of messages poses a number of problems that this pipeline construction is intended to solve.\hypertarget{md_sfcode_node_modules_websocket_extensions_lib_pipeline_README_autotoc_md34003}{}\doxysection{Overview}\label{md_sfcode_node_modules_websocket_extensions_lib_pipeline_README_autotoc_md34003}
Logically, we have the following\+:

\begin{DoxyVerb}+-------------+  out  +---+     +---+     +---+       +--------+
|             |------>|   |---->|   |---->|   |------>|        |
| Application |       | A |     | B |     | C |       | Driver |
|             |<------|   |<----|   |<----|   |<------|        |
+-------------+  in   +---+     +---+     +---+       +--------+

                      \                       /
                       +----------o----------+
                                  |
                               sessions
\end{DoxyVerb}


For outgoing messages, the driver receives the result of \begin{DoxyVerb}    C.outgoing(B.outgoing(A.outgoing(message)))

or, [A, B, C].reduce(((m, ext) => ext.outgoing(m)), message)
\end{DoxyVerb}
 For incoming messages, the application receives the result of \begin{DoxyVerb}    A.incoming(B.incoming(C.incoming(message)))

or, [C, B, A].reduce(((m, ext) => ext.incoming(m)), message)
\end{DoxyVerb}
 A session is of the following type, to borrow notation from pseudo-\/\+Haskell\+: \begin{DoxyVerb}type Session = {
  incoming :: Message -> Message
  outgoing :: Message -> Message
  close    :: () -> ()
}
\end{DoxyVerb}
 (That {\ttfamily () -\/$>$ ()} syntax is intended to mean that {\ttfamily close()} is a nullary void method; I apologise to any Haskell readers for not using the right monad.)

The {\ttfamily incoming()} and {\ttfamily outgoing()} methods perform message transformation in the respective directions; {\ttfamily close()} is called when a socket closes so the session can release any resources it\textquotesingle{}s holding, for example a DEFLATE de/compression context.

However because this is Java\+Script, the {\ttfamily incoming()} and {\ttfamily outgoing()} methods may be asynchronous (indeed, {\ttfamily permessage-\/deflate} is based on {\ttfamily zlib}, whose API is stream-\/based). So their interface is strictly\+: \begin{DoxyVerb}type Session = {
  incoming :: Message -> Callback -> ()
  outgoing :: Message -> Callback -> ()
  close    :: () -> ()
}

type Callback = Either Error Message -> ()
\end{DoxyVerb}
 This means a message {\itshape m2} can be pushed into a session while it\textquotesingle{}s still processing the preceding message {\itshape m1}. The messages can be processed concurrently but they {\itshape must} be given to the next session in line (or to the application) in the same order they came in. Applications will expect to receive messages in the order they arrived over the wire, and sessions require this too. So ordering of messages must be preserved throughout the pipeline.

Consider the following highly simplified extension that deflates messages on the wire. {\ttfamily message} is a value conforming the type\+: \begin{DoxyVerb}type Message = {
  rsv1   :: Boolean
  rsv2   :: Boolean
  rsv3   :: Boolean
  opcode :: Number
  data   :: Buffer
}
\end{DoxyVerb}
 Here\textquotesingle{}s the extension\+:


\begin{DoxyCode}{0}
\DoxyCodeLine{var zlib = require('zlib');}
\DoxyCodeLine{}
\DoxyCodeLine{var deflate = \{}
\DoxyCodeLine{  outgoing: function(message, callback) \{}
\DoxyCodeLine{    zlib.deflateRaw(message.data, function(error, result) \{}
\DoxyCodeLine{      message.rsv1 = true;}
\DoxyCodeLine{      message.data = result;}
\DoxyCodeLine{      callback(error, message);}
\DoxyCodeLine{    \});}
\DoxyCodeLine{  \},}
\DoxyCodeLine{}
\DoxyCodeLine{  incoming: function(message, callback) \{}
\DoxyCodeLine{    // decompress inbound messages (elided)}
\DoxyCodeLine{  \},}
\DoxyCodeLine{}
\DoxyCodeLine{  close: function() \{}
\DoxyCodeLine{    // no state to clean up}
\DoxyCodeLine{  \}}
\DoxyCodeLine{\}; }

\end{DoxyCode}


We can call it with a large message followed by a small one, and the small one will be returned first\+:


\begin{DoxyCode}{0}
\DoxyCodeLine{var crypto = require('crypto'),}
\DoxyCodeLine{    large  = crypto.randomBytes(1 << 14),}
\DoxyCodeLine{    small  = new Buffer('hi');}
\DoxyCodeLine{}
\DoxyCodeLine{deflate.outgoing(\{ data: large \}, function() \{}
\DoxyCodeLine{  console.log(1, 'large');}
\DoxyCodeLine{\});}
\DoxyCodeLine{}
\DoxyCodeLine{deflate.outgoing(\{ data: small \}, function() \{}
\DoxyCodeLine{  console.log(2, 'small');}
\DoxyCodeLine{\});}
\DoxyCodeLine{}
\DoxyCodeLine{/* prints:  2 'small'}
\DoxyCodeLine{            1 'large' */ }

\end{DoxyCode}


So a session that processes messages asynchronously may fail to preserve message ordering.

Now, this extension is stateless, so it can process messages in any order and still produce the same output. But some extensions are stateful and require message order to be preserved.

For example, when using {\ttfamily permessage-\/deflate} without {\ttfamily no\+\_\+context\+\_\+takeover} set, the session retains a DEFLATE de/compression context between messages, which accumulates state as it consumes data (later messages can refer to sections of previous ones to improve compression). Reordering parts of the DEFLATE stream will result in a failed decompression. Messages must be decompressed in the same order they were compressed by the peer in order for the DEFLATE protocol to work.

Finally, there is the problem of closing a socket. When a Web\+Socket is closed by the application, or receives a closing request from the other peer, there may be messages outgoing from the application and incoming from the peer in the pipeline. If we close the socket and pipeline immediately, two problems arise\+:


\begin{DoxyItemize}
\item We may send our own closing frame to the peer before all prior messages we sent have been written to the socket, and before we have finished processing all prior messages from the peer
\item The session may be instructed to close its resources (e.\+g. its de/compression context) while it\textquotesingle{}s in the middle of processing a message, or before it has received messages that are upstream of it in the pipeline
\end{DoxyItemize}

Essentially, we must defer closing the sessions and sending a closing frame until after all prior messages have exited the pipeline.\hypertarget{md_sfcode_node_modules_websocket_extensions_lib_pipeline_README_autotoc_md34004}{}\doxysection{Design goals}\label{md_sfcode_node_modules_websocket_extensions_lib_pipeline_README_autotoc_md34004}

\begin{DoxyItemize}
\item Message order must be preserved between the protocol driver, the extension sessions, and the application
\item Messages should be handed off to sessions and endpoints as soon as possible, to maximise throughput of stateless sessions
\item The closing procedure should block any further messages from entering the pipeline, and should allow all existing messages to drain
\item Sessions should be closed as soon as possible to prevent them holding memory and other resources when they have no more messages to handle
\item The closing API should allow the caller to detect when the pipeline is empty and it is safe to continue the Web\+Socket closing procedure
\item Individual extensions should remain as simple as possible to facilitate modularity and independent authorship
\end{DoxyItemize}

The final point about modularity is an important one\+: this framework is designed to facilitate extensions existing as plugins, by decoupling the protocol driver, extensions, and application. In an ideal world, plugins should only need to contain code for their specific functionality, and not solve these problems that apply to all sessions. Also, solving some of these problems requires consideration of all active sessions collectively, which an individual session is incapable of doing.

For example, it is entirely possible to take the simple {\ttfamily deflate} extension above and wrap its {\ttfamily incoming()} and {\ttfamily outgoing()} methods in two {\ttfamily Transform} streams, producing this type\+: \begin{DoxyVerb}type Session = {
  incoming :: TransformStream
  outtoing :: TransformStream
  close    :: () -> ()
}
\end{DoxyVerb}
 The {\ttfamily Transform} class makes it easy to wrap an async function such that message order is preserved\+:


\begin{DoxyCode}{0}
\DoxyCodeLine{var stream  = require('stream'),}
\DoxyCodeLine{    session = new stream.Transform(\{ objectMode: true \});}
\DoxyCodeLine{}
\DoxyCodeLine{session.\_transform = function(message, \_, callback) \{}
\DoxyCodeLine{  var self = this;}
\DoxyCodeLine{  deflate.outgoing(message, function(error, result) \{}
\DoxyCodeLine{    self.push(result);}
\DoxyCodeLine{    callback();}
\DoxyCodeLine{  \});}
\DoxyCodeLine{\}; }

\end{DoxyCode}


However, this has a negative impact on throughput\+: it works by deferring {\ttfamily callback()} until the async function has \textquotesingle{}returned\textquotesingle{}, which blocks {\ttfamily Transform} from passing further input into the {\ttfamily \+\_\+transform()} method until the current message is dealt with completely. This would prevent sessions from processing messages concurrently, and would unnecessarily reduce the throughput of stateless extensions.

So, input should be handed off to sessions as soon as possible, and all we need is a mechanism to reorder the output so that message order is preserved for the next session in line.\hypertarget{md_sfcode_node_modules_websocket_extensions_lib_pipeline_README_autotoc_md34005}{}\doxysection{Solution}\label{md_sfcode_node_modules_websocket_extensions_lib_pipeline_README_autotoc_md34005}
We now describe the model implemented here and how it meets the above design goals. The above diagram where a stack of extensions sit between the driver and application describes the data flow, but not the object graph. That looks like this\+:

\begin{DoxyVerb}        +--------+
        | Driver |
        +---o----+
            |
            V
      +------------+      +----------+
      | Extensions o----->| Pipeline |
      +------------+      +-----o----+
                                |
                +---------------+---------------+
                |               |               |
          +-----o----+    +-----o----+    +-----o----+
          | Cell [A] |    | Cell [B] |    | Cell [C] |
          +----------+    +----------+    +----------+
\end{DoxyVerb}


A driver using this framework holds an instance of the {\ttfamily Extensions} class, which it uses to register extension plugins, negotiate headers and transform messages. The {\ttfamily Extensions} instance itself holds a {\ttfamily Pipeline}, which contains an array of {\ttfamily Cell} objects, each of which wraps one of the sessions.\hypertarget{md_sfcode_node_modules_websocket_extensions_lib_pipeline_README_autotoc_md34006}{}\doxysubsection{Message processing}\label{md_sfcode_node_modules_websocket_extensions_lib_pipeline_README_autotoc_md34006}
Both the {\ttfamily Pipeline} and {\ttfamily Cell} classes have {\ttfamily incoming()} and {\ttfamily outgoing()} methods; the {\ttfamily Pipeline} interface pushes messages into the pipe, delegates the message to each {\ttfamily Cell} in turn, then returns it back to the driver. Outgoing messages pass through {\ttfamily A} then {\ttfamily B} then {\ttfamily C}, and incoming messages in the reverse order.

Internally, a {\ttfamily Cell} contains two {\ttfamily Functor} objects. A {\ttfamily Functor} wraps an async function and makes sure its output messages maintain the order of its input messages. This name is due to \href{https://github.com/fronx}{\texttt{ @fronx}}, on the basis that, by preserving message order, the abstraction preserves the {\itshape mapping} between input and output messages. To use our simple {\ttfamily deflate} extension from above\+:


\begin{DoxyCode}{0}
\DoxyCodeLine{var functor = new Functor(deflate, 'outgoing');}
\DoxyCodeLine{}
\DoxyCodeLine{functor.call(\{ data: large \}, function() \{}
\DoxyCodeLine{  console.log(1, 'large');}
\DoxyCodeLine{\});}
\DoxyCodeLine{}
\DoxyCodeLine{functor.call(\{ data: small \}, function() \{}
\DoxyCodeLine{  console.log(2, 'small');}
\DoxyCodeLine{\});}
\DoxyCodeLine{}
\DoxyCodeLine{/*  -\/>  1 'large'}
\DoxyCodeLine{        2 'small' */ }

\end{DoxyCode}


A {\ttfamily Cell} contains two of these, one for each direction\+:

\begin{DoxyVerb}                        +-----------------------+
                  +---->| Functor [A, incoming] |
+----------+      |     +-----------------------+
| Cell [A] o------+
+----------+      |     +-----------------------+
                  +---->| Functor [A, outgoing] |
                        +-----------------------+
\end{DoxyVerb}


This satisfies the message transformation requirements\+: the {\ttfamily Pipeline} simply loops over the cells in the appropriate direction to transform each message. Because each {\ttfamily Cell} will preserve message order, we can pass a message to the next {\ttfamily Cell} in line as soon as the current {\ttfamily Cell} returns it. This gives each {\ttfamily Cell} all the messages in order while maximising throughput.\hypertarget{md_sfcode_node_modules_websocket_extensions_lib_pipeline_README_autotoc_md34007}{}\doxysubsection{Session closing}\label{md_sfcode_node_modules_websocket_extensions_lib_pipeline_README_autotoc_md34007}
We want to close each session as soon as possible, after all existing messages have drained. To do this, each {\ttfamily Cell} begins with a pending message counter in each direction, labelled {\ttfamily in} and {\ttfamily out} below.

\begin{DoxyVerb}                          +----------+
                          | Pipeline |
                          +-----o----+
                                |
                +---------------+---------------+
                |               |               |
          +-----o----+    +-----o----+    +-----o----+
          | Cell [A] |    | Cell [B] |    | Cell [C] |
          +----------+    +----------+    +----------+
             in: 0           in: 0           in: 0
            out: 0          out: 0          out: 0
\end{DoxyVerb}


When a message {\itshape m1} enters the pipeline, say in the {\ttfamily outgoing} direction, we increment the {\ttfamily pending.\+out} counter on all cells immediately.

\begin{DoxyVerb}                          +----------+
                    m1 => | Pipeline |
                          +-----o----+
                                |
                +---------------+---------------+
                |               |               |
          +-----o----+    +-----o----+    +-----o----+
          | Cell [A] |    | Cell [B] |    | Cell [C] |
          +----------+    +----------+    +----------+
             in: 0           in: 0           in: 0
            out: 1          out: 1          out: 1
\end{DoxyVerb}


{\itshape m1} is handed off to {\ttfamily A}, meanwhile a second message {\ttfamily m2} arrives in the same direction. All {\ttfamily pending.\+out} counters are again incremented.

\begin{DoxyVerb}                          +----------+
                    m2 => | Pipeline |
                          +-----o----+
                                |
                +---------------+---------------+
            m1  |               |               |
          +-----o----+    +-----o----+    +-----o----+
          | Cell [A] |    | Cell [B] |    | Cell [C] |
          +----------+    +----------+    +----------+
             in: 0           in: 0           in: 0
            out: 2          out: 2          out: 2
\end{DoxyVerb}


When the first cell\textquotesingle{}s {\ttfamily A.\+outgoing} functor finishes processing {\itshape m1}, the first {\ttfamily pending.\+out} counter is decremented and {\itshape m1} is handed off to cell {\ttfamily B}.

\begin{DoxyVerb}                          +----------+
                          | Pipeline |
                          +-----o----+
                                |
                +---------------+---------------+
            m2  |           m1  |               |
          +-----o----+    +-----o----+    +-----o----+
          | Cell [A] |    | Cell [B] |    | Cell [C] |
          +----------+    +----------+    +----------+
             in: 0           in: 0           in: 0
            out: 1          out: 2          out: 2
\end{DoxyVerb}


As {\ttfamily B} finishes with {\itshape m1}, and as {\ttfamily A} finishes with {\itshape m2}, the {\ttfamily pending.\+out} counters continue to decrement.

\begin{DoxyVerb}                          +----------+
                          | Pipeline |
                          +-----o----+
                                |
                +---------------+---------------+
                |           m2  |           m1  |
          +-----o----+    +-----o----+    +-----o----+
          | Cell [A] |    | Cell [B] |    | Cell [C] |
          +----------+    +----------+    +----------+
             in: 0           in: 0           in: 0
            out: 0          out: 1          out: 2
\end{DoxyVerb}


Say {\ttfamily C} is a little slow, and begins processing {\itshape m2} while still processing {\itshape m1}. That\textquotesingle{}s fine, the {\ttfamily Functor} mechanism will keep {\itshape m1} ahead of {\itshape m2} in the output.

\begin{DoxyVerb}                          +----------+
                          | Pipeline |
                          +-----o----+
                                |
                +---------------+---------------+
                |               |           m2  | m1
          +-----o----+    +-----o----+    +-----o----+
          | Cell [A] |    | Cell [B] |    | Cell [C] |
          +----------+    +----------+    +----------+
             in: 0           in: 0           in: 0
            out: 0          out: 0          out: 2
\end{DoxyVerb}


Once all messages are dealt with, the counters return to {\ttfamily 0}.

\begin{DoxyVerb}                          +----------+
                          | Pipeline |
                          +-----o----+
                                |
                +---------------+---------------+
                |               |               |
          +-----o----+    +-----o----+    +-----o----+
          | Cell [A] |    | Cell [B] |    | Cell [C] |
          +----------+    +----------+    +----------+
             in: 0           in: 0           in: 0
            out: 0          out: 0          out: 0
\end{DoxyVerb}


The same process applies in the {\ttfamily incoming} direction, the only difference being that messages are passed to {\ttfamily C} first.

This makes closing the sessions quite simple. When the driver wants to close the socket, it calls {\ttfamily Pipeline.\+close()}. This {\itshape immediately} calls {\ttfamily close()} on all the cells. If a cell has {\ttfamily in == out == 0}, then it immediately calls {\ttfamily session.\+close()}. Otherwise, it stores the closing call and defers it until {\ttfamily in} and {\ttfamily out} have both ticked down to zero. The pipeline will not accept new messages after {\ttfamily close()} has been called, so we know the pending counts will not increase after this point.

This means each session is closed as soon as possible\+: {\ttfamily A} can close while the slow {\ttfamily C} session is still working, because it knows there are no more messages on the way. Similarly, {\ttfamily C} will defer closing if {\ttfamily close()} is called while {\itshape m1} is still in {\ttfamily B}, and {\itshape m2} in {\ttfamily A}, because its pending count means it knows it has work yet to do, even if it\textquotesingle{}s not received those messages yet. This concern cannot be addressed by extensions acting only on their own local state, unless we pollute individual extensions by making them all implement this same mechanism.

The actual closing API at each level is slightly different\+: \begin{DoxyVerb}type Session = {
  close :: () -> ()
}

type Cell = {
  close :: () -> Promise ()
}

type Pipeline = {
  close :: Callback -> ()
}
\end{DoxyVerb}
 This might appear inconsistent so it\textquotesingle{}s worth explaining. Remember that a {\ttfamily Pipeline} holds a list of {\ttfamily Cell} objects, each wrapping a {\ttfamily Session}. The driver talks (via the {\ttfamily Extensions} API) to the {\ttfamily Pipeline} interface, and it wants {\ttfamily Pipeline.\+close()} to do two things\+: close all the sessions, and tell me when it\textquotesingle{}s safe to start the closing procedure (i.\+e. when all messages have drained from the pipe and been handed off to the application or socket). A callback API works well for that.

At the other end of the stack, {\ttfamily Session.\+close()} is a nullary void method with no callback or promise API because we don\textquotesingle{}t care what it does, and whatever it does do will not block the Web\+Socket protocol; we\textquotesingle{}re not going to hold off processing messages while a session closes its de/compression context. We just tell it to close itself, and don\textquotesingle{}t want to wait while it does that.

In the middle, {\ttfamily Cell.\+close()} returns a promise rather than using a callback. This is for two reasons. First, {\ttfamily Cell.\+close()} might not do anything immediately, it might have to defer its effect while messages drain. So, if given a callback, it would have to store it in a queue for later execution. Callbacks work fine if your method does something and can then invoke the callback itself, but if you need to store callbacks somewhere so another method can execute them, a promise is a better fit. Second, it better serves the purposes of {\ttfamily Pipeline.\+close()}\+: it wants to call {\ttfamily close()} on each of a list of cells, and wait for all of them to finish. This is simple and idiomatic using promises\+:


\begin{DoxyCode}{0}
\DoxyCodeLine{var closed = cells.map((cell) => cell.close());}
\DoxyCodeLine{Promise.all(closed).then(callback); }

\end{DoxyCode}


(We don\textquotesingle{}t actually use a full {\itshape Promises/\+A+} compatible promise here, we use a much simplified construction that acts as a callback aggregater and resolves synchronously and does not support chaining, but the principle is the same.)\hypertarget{md_sfcode_node_modules_websocket_extensions_lib_pipeline_README_autotoc_md34008}{}\doxysubsection{Error handling}\label{md_sfcode_node_modules_websocket_extensions_lib_pipeline_README_autotoc_md34008}
We\textquotesingle{}ve not mentioned error handling so far but it bears some explanation. The above counter system still applies, but behaves slightly differently in the presence of errors.

Say we push three messages into the pipe in the outgoing direction\+:

\begin{DoxyVerb}                          +----------+
            m3, m2, m1 => | Pipeline |
                          +-----o----+
                                |
                +---------------+---------------+
                |               |               |
          +-----o----+    +-----o----+    +-----o----+
          | Cell [A] |    | Cell [B] |    | Cell [C] |
          +----------+    +----------+    +----------+
             in: 0           in: 0           in: 0
            out: 3          out: 3          out: 3
\end{DoxyVerb}


They pass through the cells successfully up to this point\+:

\begin{DoxyVerb}                          +----------+
                          | Pipeline |
                          +-----o----+
                                |
                +---------------+---------------+
            m3  |           m2  |           m1  |
          +-----o----+    +-----o----+    +-----o----+
          | Cell [A] |    | Cell [B] |    | Cell [C] |
          +----------+    +----------+    +----------+
             in: 0           in: 0           in: 0
            out: 1          out: 2          out: 3
\end{DoxyVerb}


At this point, session {\ttfamily B} produces an error while processing {\itshape m2}, that is {\itshape m2} becomes {\itshape e2}. {\itshape m1} is still in the pipeline, and {\itshape m3} is queued behind {\itshape m2}. What ought to happen is that {\itshape m1} is handed off to the socket, then {\itshape m2} is released to the driver, which will detect the error and begin closing the socket. No further processing should be done on {\itshape m3} and it should not be released to the driver after the error is emitted.

To handle this, we allow errors to pass down the pipeline just like messages do, to maintain ordering. But, once a cell sees its session produce an error, or it receives an error from upstream, it should refuse to accept any further messages. Session {\ttfamily B} might have begun processing {\itshape m3} by the time it produces the error {\itshape e2}, but {\ttfamily C} will have been given {\itshape e2} before it receives {\itshape m3}, and can simply drop {\itshape m3}.

Now, say {\itshape e2} reaches the slow session {\ttfamily C} while {\itshape m1} is still present, meanwhile {\itshape m3} has been dropped. {\ttfamily C} will never receive {\itshape m3} since it will have been dropped upstream. Under the present model, its {\ttfamily out} counter will be {\ttfamily 3} but it is only going to emit two more values\+: {\itshape m1} and {\itshape e2}. In order for closing to work, we need to decrement {\ttfamily out} to reflect this. The situation should look like this\+:

\begin{DoxyVerb}                          +----------+
                          | Pipeline |
                          +-----o----+
                                |
                +---------------+---------------+
                |               |           e2  | m1
          +-----o----+    +-----o----+    +-----o----+
          | Cell [A] |    | Cell [B] |    | Cell [C] |
          +----------+    +----------+    +----------+
             in: 0           in: 0           in: 0
            out: 0          out: 0          out: 2
\end{DoxyVerb}


When a cell sees its session emit an error, or when it receives an error from upstream, it sets its pending count in the appropriate direction to equal the number of messages it is {\itshape currently} processing. It will not accept any messages after it sees the error, so this will allow the counter to reach zero.

Note that while {\itshape e2} is in the pipeline, {\ttfamily Pipeline} should drop any further messages in the outgoing direction, but should continue to accept incoming messages. Until {\itshape e2} makes it out of the pipe to the driver, behind previous successful messages, the driver does not know an error has happened, and a message may arrive over the socket and make it all the way through the incoming pipe in the meantime. We only halt processing in the affected direction to avoid doing unnecessary work since messages arriving after an error should not be processed.

Some unnecessary work may happen, for example any messages already in the pipeline following {\itshape m2} will be processed by {\ttfamily A}, since it\textquotesingle{}s upstream of the error. Those messages will be dropped by {\ttfamily B}.\hypertarget{md_sfcode_node_modules_websocket_extensions_lib_pipeline_README_autotoc_md34009}{}\doxysection{Alternative ideas}\label{md_sfcode_node_modules_websocket_extensions_lib_pipeline_README_autotoc_md34009}
I am considering implementing {\ttfamily Functor} as an object-\/mode transform stream rather than what is essentially an async function. Being object-\/mode, a stream would preserve message boundaries and would also possibly help address back-\/pressure. I\textquotesingle{}m not sure whether this would require external API changes so that such streams could be connected to the downstream driver\textquotesingle{}s streams.\hypertarget{md_sfcode_node_modules_websocket_extensions_lib_pipeline_README_autotoc_md34010}{}\doxysection{Acknowledgements}\label{md_sfcode_node_modules_websocket_extensions_lib_pipeline_README_autotoc_md34010}
Credit is due to \href{https://github.com/mnowster}{\texttt{ @mnowster}} for helping with the design and to \href{https://github.com/fronx}{\texttt{ @fronx}} for helping name things. 