Lines Matching refs:stream
32 + [New APIs for Single-Stream Operation](#new-apis-for-single-stream-operation)
41 - [`SSL_stream_conclude`](#-ssl-stream-conclude-)
42 - [`SSL_stream_reset`](#-ssl-stream-reset-)
43 - [`SSL_get_stream_state`](#-ssl-get-stream-state-)
44 …ror_code`, `SSL_get_stream_write_error_code`](#-ssl-get-stream-read-error-code----ssl-get-stream-w…
46 + [New APIs for Multi-Stream Operation](#new-apis-for-multi-stream-operation)
52 - [`SSL_get_stream_type`](#-ssl-get-stream-type-)
53 - [`SSL_get_stream_id`](#-ssl-get-stream-id-)
54 - [`SSL_is_stream_local`](#-ssl-is-stream-local-)
55 - [`SSL_new_stream`](#-ssl-new-stream-)
56 - [`SSL_accept_stream`](#-ssl-accept-stream-)
57 - [`SSL_get_accept_stream_queue_len`](#-ssl-get-accept-stream-queue-len-)
58 - [`SSL_set_incoming_stream_policy`](#-ssl-set-incoming-stream-policy-)
59 - [`SSL_set_default_stream_mode`](#-ssl-set-default-stream-mode-)
153 SSL object. QUIC stream SSL objects do not allow these calls to be
160 Fails on a QUIC stream SSL object.
164 - **S**: Requires a QUIC stream SSL object or a QUIC connection SSL object
165 with a default stream attached.
227 If the read part of the stream has been finished by the peer, calls to
230 If a stream has terminated in a non-normal fashion (for example because the
231 stream has been reset, or the connection has terminated), calls to `SSL_read`
234 `SSL_get_stream_read_state` can be used to clarify the stream state when an
254 `SSL_get_stream_write_state` can be used to clarify the stream state when an
274 data in the stream receive buffer.
308 **TBD:** Semantics of this on stream objects.
316 **QUIC stream SSL objects.** When used on a QUIC stream SSL object, parts of the
317 stream state may continue to exist internally, managed inside the QUIC
321 If a QUIC stream SSL object is freed for a stream which has not reached a
323 stream is automatically reset (non-normal termination) with an application error
324 code of 0. To explicitly reset a stream with a different application error code,
327 If the peer continues to send data on the stream before it processes the
328 notification of the stream's termination, that incoming data will be discarded.
330 stream assuming that the connection remains healthy.
332 When freeing a QUIC stream SSL object which was terminated in a non-normal
334 any data which was appended to the stream via `SSL_write` may or may not have
338 When freeing a QUIC stream SSL object which was terminated normally (for example
339 via `SSL_stream_conclude`), data appended to the stream via `SSL_write` will
391 - Fails (no-op) for a QUIC stream SSL object.
472 Use on stream objects: It may be feasible to implement this such that different
473 QUIC stream SSL objects can have different settings for this option.
575 Any application stream data on a non-terminated or normally terminated stream
582 end-of-stream conditions) may not be transmitted to the peer. This flag may be
585 stream data on streams which were terminated non-normally (for example via
627 Calling `SSL_shutdown_ex` on a QUIC stream SSL object is not valid; such a call
653 `SSL_stream_conclude` signals the normal end-of-stream condition to the send
654 part of a QUIC stream. If called on a QUIC connection SSL object with a default
655 stream, it signals the end of that stream to the peer. If called on a QUIC
656 stream SSL object, it signals the end of that stream to the peer.
660 stream, or if either the stream or connection have entered an error state.
663 be written in a reliable manner before the end-of-stream is signalled, assuming
665 logical end-of-stream marker after any data which has previously been written to
666 the stream via calls to `SSL_write`. Further attempts to call `SSL_write` after
669 When calling this on a bidirectional stream, the receive part of the stream
671 also signals the end of the stream. Thus, `SSL_read()` can still be used.
673 This function is used to conclude the send part of a stream in a normal manner.
675 stream, see `SSL_stream_reset`.
696 stream. For QUIC, this corresponds to a stream reset using a `RESET_STREAM`
699 It may be called on either a QUIC stream SSL object or a QUIC connection SSL
700 object with a default stream; the given stream is reset. The QUIC connection is
704 the stream. It may not be called on an incoming unidirectional stream.
723 * stream.
728 * The read or write part of the stream is still available and has not been
734 * The stream is a unidirectional stream and this direction cannot be used; for
735 * example, a remotely initiated unidirectional stream where
737 * stream where SSL_get_stream_read_state is
743 * The read or write part of the stream has been finished in a normal manner.
750 * already indicated the end of the stream by calling SSL_stream_conclude,
756 * The stream was reset by the local party.
758 * For SSL_get_stream_read_state, this means that the stream was aborted using a
759 * locally transmitted STOP_SENDING frame. Attempts to read from the stream via
763 * For SSL_get_stream_write_state, this means that the stream was aborted
765 * the stream will fail.
770 * The stream was reset by the remote party.
773 * frame for the stream.
776 * frame for the stream.
781 * The underlying connection supporting the stream has closed or otherwise
785 * stream via SSL_read will fail, though SSL_read may allow any residual
789 * stream will fail.
797 This API allows the current state of a stream to be queried. This allows an
798 application to determine whether a stream is still usable and why a stream has
813 stream.
816 the stream.
818 If a stream has been terminated normally, returns 0.
820 If a stream has been terminated non-normally, returns 1 and writes the
823 If a stream is still healthy, or was healthy at the time the connection was
824 closed, or the respective part of the stream does not exist (e.g. for a
825 unidirectional stream), returns -1.
869 The above new APIs are built on constructively to facilitate multi-stream
872 The concept of a QUIC stream SSL object is introduced. A QUIC SSL object is
873 either a QUIC connection SSL object or a QUIC stream SSL object. A QUIC stream
875 may or may not have an associated default stream. There may only be at most one
876 default stream for a QUIC connection SSL object. Reading or writing application
877 data to a QUIC connection SSL object with a default stream is equivalent to
878 reading or writing to that stream. It is an error to attempt to read or write
879 application data, or perform other stream-specific operations, on a QUIC
880 connection SSL object without a default stream associated.
886 stream SSL objects on different threads over the same connection without the
887 application having to do any locking. This is referred to as multi-stream
894 stream SSL object is created it inherits its blocking state from the currently
896 stream is created. This can be changed independently. For example, a QUIC
898 `SSL_accept_stream` calls, yet have some or all QUIC stream SSL objects be in
904 connection SSL objects efficiently for new stream and stream readability events.
921 * If the SSL object represents a QUIC stream returns the QUIC connection
952 * If the object represents a stream, returns a SSL_STREAM_TYPE value
953 * designating whether the stream can be used for transmission, reception,
959 * does not have a default stream.
976 * QUIC: Returns the unique stream ID for the stream, an integer in range [0, 2**62-1],
977 * or UINT64_MAX if the stream ID is not available. If called on a QUIC
978 * connection, returns the unique stream ID for the default stream if there is
994 * QUIC: Returns 1 if the stream was locally initiated, or 0 otherwise.
1009 * Create a new SSL object representing a single additional stream.
1015 * Creates a new stream. Must be called only on a QUIC connection SSL object.
1017 * the created stream is unidirectional, otherwise it is bidirectional.
1037 * Create a new SSL object representing an additional stream which was created
1045 * stream object. Checks if a new stream has been created by the peer. If it
1048 * stream (that is, the stream with the lowest stream ID) is accepted.
1060 * This function returns NULL if the effective incoming stream reject policy is
1079 * non-QUIC objects, or for QUIC stream objects.
1096 * - if the default stream mode is
1126 * Used to control single stream operation. Calling this function determines the
1127 * nature of the default stream which will automatically be created on the QUIC
1134 * - `SSL_DEFAULT_STREAM_MODE_NONE`: No default stream will ever be created.
1135 * The application is assumed to understand multi-stream operation.
1138 * stream SSL object, not the QUIC connection SSL object, as no default
1139 * stream will be associated with it.
1141 * - `SSL_DEFAULT_STREAM_MODE_AUTO_BIDI`: "First stream wins" mode of
1142 * operation for single-stream usage. If `SSL_write` is called before the
1143 * peer opens a remotely-initiated stream, a locally-initiated bidirectional
1144 * stream is created and bound as the default stream. If the peer opens a
1145 * remotely-initiated stream before the local application calls `SSL_write`
1146 * (with `len > 0`) for the first time, that stream is bound as the default
1147 * stream, which may be bidirectional or unidirectional; if it is
1152 * - `SSL_DEFAULT_STREAM_MODE_AUTO_UNI`: "First stream wins" mode of
1153 * operation for single-stream usage, with a unidirectional stream. This
1156 * remotely-initiated stream, a unidirectional TX-only stream is created and
1157 * bound as the default stream. Thereafter, calls to `SSL_read` will fail.
1158 * If the peer creates a remotely-initiated stream prior to the first call
1159 * to `SSL_write` (with `len > 0`), that stream will be bound as the default
1160 * stream; note that a bidirectional stream may be bound in this case.
1164 * This function must be called before a default stream object is created, for
1550 QUIC stream SSL object.
1552 **Q. Can data be received on a locally initiated bidirectional stream before any
1553 data is sent on that stream?**
1560 >An implementation might choose to defer allocating a stream ID to a stream until
1562 >better stream prioritization.
1564 If an ID has not been allocated to a stream, obviously incoming data cannot be
1567 stream locally, then receive data on it before sending anything:
1569 >The sending part of a stream that the endpoint initiates (types 0 and 2 for
1571 >state represents a newly created stream that is able to accept data from the
1576 >For a bidirectional stream, the receiving part enters the "Recv" state when
1580 A peer is not generally notified of the creation of a stream which has not sent
1581 any data yet, since the creation of a stream is signalled only implicitly via
1585 order to receive data on a locally-initiated bidirectional stream before sending
1586 any data on that stream, it would be necessary to either
1588 - Use a QUIC implementation which signals a bidirectional stream which has
1589 not yet sent any data via a zero-length stream frame, or
1591 - Use an application protocol which can inform the peer of the stream ID
1592 of the created stream in some application protocol-specific way.
1595 that the peer has in fact created a stream with a given ID and to
1601 application would want to create a locally-initiated stream and then have the
1602 peer transmit on it first, rather than simply use a remotely-initiated stream.
1606 **Q. How should single-stream operation support locally and remotely-initiated
1609 Note that the ID of a stream depends on whether it is bidirectional and whether
1610 it is initiated by the client or server. Therefore, in single stream operation,
1611 it is necessary to know whether single-stream QUIC is being used with
1612 client-initiated or server-initiated stream initiation, and whether a
1613 bidirectional or unidirectional stream is being used; otherwise, we do not know
1614 which stream ID to bind to.
1616 The object of single stream operation is to support simple uses cases for simple
1618 receiving first on a locally initiated stream here, thus we avoid supporting
1622 before it calls `SSL_read` by definition is using a locally-initiated stream,
1623 and an application which does the opposite is using a remotely-initiated stream.
1625 the desired stream type.
1628 we automatically create the stream and queue data for transmission.
1631 stranger. We could create the stream with the correct ID when cued to by the
1632 initial call to `SSL_read` implying use of a remotely-initiated stream. However,
1633 this would mean we are creating state tracking a remotely-initiated stream
1640 Ergo, creation of a default remotely-initiated stream needs to be deferred
1641 until the *peer* signals such a stream.
1643 This leads naturally to a "first stream wins" model of implementation:
1645 - When a QUIC connection SSL object is created, default stream mode is
1646 enabled, meaning that a default stream will be bound to the QUIC connection
1648 stream is bound yet.
1653 stream with ordinal 0 is created. The stream is bidirectional by default but
1654 this can be changed. This stream is bound as the default stream.
1656 - The peer creates a stream. This stream is bound as the default stream.
1662 Once one of the above events occurs, any additional stream created by the peer
