Stream

Event-driven readable and writable streams for non-blocking I/O in ReactPHP.

Development version: This branch contains the code for the upcoming v3 release. For the code of the current stable v1 release, check out the 1.x branch.

The upcoming v3 release will be the way forward for this package. However, we will still actively support v1 for those not yet on the latest version. See also installation instructions for more details.

In order to make the EventLoop easier to use, this component introduces the powerful concept of "streams". Streams allow you to efficiently process huge amounts of data (such as a multi Gigabyte file download) in small chunks without having to store everything in memory at once. They are very similar to the streams found in PHP itself, but have an interface more suited for async, non-blocking I/O.

Table of contents

• Stream usage
  • ReadableStreamInterface
    • data event
    • end event
    • error event
    • close event
    • isReadable()
    • pause()
    • resume()
    • pipe()
    • close()
  • WritableStreamInterface
    • drain event
    • pipe event
    • error event
    • close event
    • isWritable()
    • write()
    • end()
    • close()
  • DuplexStreamInterface
• Creating streams
  • ReadableResourceStream
  • WritableResourceStream
  • DuplexResourceStream
  • ThroughStream
  • CompositeStream
• Usage
• Install
• Tests
• License
• More

Stream usage

ReactPHP uses the concept of "streams" throughout its ecosystem to provide a consistent higher-level abstraction for processing streams of arbitrary data contents and size. While a stream itself is a quite low-level concept, it can be used as a powerful abstraction to build higher-level components and protocols on top.

If you're new to this concept, it helps to think of them as a water pipe: You can consume water from a source or you can produce water and forward (pipe) it to any destination (sink).

Similarly, streams can either be

• readable (such as STDIN terminal input) or
• writable (such as STDOUT terminal output) or
• duplex (both readable and writable, such as a TCP/IP connection)

Accordingly, this package defines the following three interfaces

• ReadableStreamInterface
• WritableStreamInterface
• DuplexStreamInterface

ReadableStreamInterface

The ReadableStreamInterface is responsible for providing an interface for read-only streams and the readable side of duplex streams.

Besides defining a few methods, this interface also implements the EventEmitterInterface which allows you to react to certain events.

The event callback functions MUST be a valid callable that obeys strict parameter definitions and MUST accept event parameters exactly as documented. The event callback functions MUST NOT throw an Exception. The return value of the event callback functions will be ignored and has no effect, so for performance reasons you're recommended to not return any excessive data structures.

Every implementation of this interface MUST follow these event semantics in order to be considered a well-behaving stream.

Note that higher-level implementations of this interface may choose to define additional events with dedicated semantics not defined as part of this low-level stream specification. Conformance with these event semantics is out of scope for this interface, so you may also have to refer to the documentation of such a higher-level implementation.

data event

The data event will be emitted whenever some data was read/received from this source stream. The event receives a single mixed argument for incoming data.

$stream->on('data', function (mixed $data): void {
    echo $data;
});

This event MAY be emitted any number of times, which may be zero times if this stream does not send any data at all. It SHOULD not be emitted after an end or close event.

The given $data argument may be of mixed type, but it's usually recommended it SHOULD be a string value or MAY use a type that allows representation as a string for maximum compatibility.

Many common streams (such as a TCP/IP connection or a file-based stream) will emit the raw (binary) payload data that is received over the wire as chunks of string values.

Due to the stream-based nature of this, the sender may send any number of chunks with varying sizes. There are no guarantees that these chunks will be received with the exact same framing the sender intended to send. In other words, many lower-level protocols (such as TCP/IP) transfer the data in chunks that may be anywhere between single-byte values to several dozens of kilobytes. You may want to apply a higher-level protocol to these low-level data chunks in order to achieve proper message framing.

end event

The end event will be emitted once the source stream has successfully reached the end of the stream (EOF).

$stream->on('end', function (): void {
    echo 'END';
});

This event SHOULD be emitted once or never at all, depending on whether a successful end was detected. It SHOULD NOT be emitted after a previous end or close event. It MUST NOT be emitted if the stream closes due to a non-successful end, such as after a previous error event.

After the stream is ended, it MUST switch to non-readable mode, see also isReadable().

This event will only be emitted if the end was reached successfully, not if the stream was interrupted by an unrecoverable error or explicitly closed. Not all streams know this concept of a "successful end". Many use-cases involve detecting when the stream closes (terminates) instead, in this case you should use the close event. After the stream emits an end event, it SHOULD usually be followed by a close event.

Many common streams (such as a TCP/IP connection or a file-based stream) will emit this event if either the remote side closes the connection or a file handle was successfully read until reaching its end (EOF).

Note that this event should not be confused with the end() method. This event defines a successful end reading from a source stream, while the end() method defines writing a successful end to a destination stream.

error event

The error event will be emitted once a fatal error occurs, usually while trying to read from this stream. The event receives a single Exception argument for the error instance.

$server->on('error', function (Exception $e): void {
    echo 'Error: ' . $e->getMessage() . PHP_EOL;
});

This event SHOULD be emitted once the stream detects a fatal error, such as a fatal transmission error or after an unexpected data or premature end event. It SHOULD NOT be emitted after a previous error, end or close event. It MUST NOT be emitted if this is not a fatal error condition, such as a temporary network issue that did not cause any data to be lost.

After the stream errors, it MUST close the stream and SHOULD thus be followed by a close event and then switch to non-readable mode, see also close() and isReadable().

Many common streams (such as a TCP/IP connection or a file-based stream) only deal with data transmission and do not make assumption about data boundaries (such as unexpected data or premature end events). In other words, many lower-level protocols (such as TCP/IP) may choose to only emit this for a fatal transmission error once and will then close (terminate) the stream in response.

If this stream is a DuplexStreamInterface, you should also notice how the writable side of the stream also implements an error event. In other words, an error may occur while either reading or writing the stream which should result in the same error processing.

close event

The close event will be emitted once the stream closes (terminates).

$stream->on('close', function (): void {
    echo 'CLOSED';
});

This event SHOULD be emitted once or never at all, depending on whether the stream ever terminates. It SHOULD NOT be emitted after a previous close event.

After the stream is closed, it MUST switch to non-readable mode, see also isReadable().

Unlike the end event, this event SHOULD be emitted whenever the stream closes, irrespective of whether this happens implicitly due to an unrecoverable error or explicitly when either side closes the stream. If you only want to detect a successful end, you should use the end event instead.

Many common streams (such as a TCP/IP connection or a file-based stream) will likely choose to emit this event after reading a successful end event or after a fatal transmission error event.

If this stream is a DuplexStreamInterface, you should also notice how the writable side of the stream also implements a close event. In other words, after receiving this event, the stream MUST switch into non-writable AND non-readable mode, see also isWritable(). Note that this event should not be confused wi