Lines Matching refs:stream
6 demos/guide/quic-multi-stream.c
12 ossl-guide-quic-multi-stream
13 - OpenSSL Guide: Writing a simple multi-stream QUIC client
18 QUIC multi-stream application. It assumes a basic understanding of QUIC and how
24 In a QUIC multi-stream application we separate out the concepts of a QUIC
25 "connection" and a QUIC "stream". A connection object represents the overarching
33 normally you would have at least one). A stream is used to send and receive
34 data between the two peers. Each stream is also represented by an B<SSL>
35 object. A stream is logically independent of all the other streams associated
36 with the same connection. Data sent on a stream is guaranteed to be delivered
37 in the order that it was sent within that stream. The same is not true across
38 streams, e.g. if an application sends data on stream 1 first and then sends some
39 more data on stream 2 second, then the remote peer may receive the data sent on
40 stream 2 before it receives the data sent on stream 1.
43 L<SSL_connect(3)> has returned 1), stream B<SSL> objects are created by the
50 use an B<SSL> object representing one stream at the same time as another thread
51 is using a different B<SSL> object for a different stream on the same
57 A connection B<SSL> object may also (optionally) be associated with a stream.
58 This stream is known as the default stream. The default stream is automatically
64 (by default) the default stream will be a client-initiated bi-directional
65 stream. If a client application calls L<SSL_read_ex(3)> or L<SSL_read(3)>
66 first then the first stream initiated by the server will be used as the default
67 stream (whether it is bi-directional or uni-directional).
69 This behaviour can be controlled via the default stream mode. See
72 It is recommended that new multi-stream applications should not use a default
73 stream at all and instead should use a separate stream B<SSL> object for each
74 stream that is used. This requires calling L<SSL_set_default_stream_mode(3)>
79 An endpoint can create a new stream by calling L<SSL_new_stream(3)>. This
80 creates a locally initiated stream. In order to do so you must pass the QUIC
82 bi-directional or a uni-directional stream.
84 The function returns a new QUIC stream B<SSL> object for sending and receiving
85 data on that stream.
91 a remotely initiated stream. If the peer has not initiated any then this call
95 When using a default stream OpenSSL will prevent new streams from being
99 is not relevant if the default stream has been disabled as described in
102 Any stream may be bi-directional or uni-directional. If it is uni-directional
104 peer. You can determine what type of stream an B<SSL> object represents by
109 Once you have a stream B<SSL> object (which includes the connection B<SSL>
110 object if a default stream is in use) then you can send and receive data over it
118 when attempting to read data from a stream and the peer has indicated that the
119 stream is concluded (i.e. "FIN" has been signalled on the stream). This means
120 that the peer will send no more data on that stream. Note that the
124 stream has been concluded by the peer. It tells you nothing about the underlying
125 connection. If the peer has concluded the stream then no more data will be
127 the send side of the stream has also been concluded. This can happen by the
129 send more data on a stream after L<SSL_stream_conclude(3)> has been called.
131 It is also possible to abandon a stream abnormally by calling
134 Once a stream object is no longer needed it should be freed via a call to
136 this is only meaningful for connection level B<SSL> objects. Freeing the stream
141 Given a stream object it is possible to get the B<SSL> object corresponding to
144 object. Specifically, if you are handling each of your stream objects in a
151 A stream object does not inherit all its settings and values from its parent
153 the connection as a whole will not work on a stream. For example the function
155 when called with a connection B<SSL> object. When called with a stream B<SSL>
161 a simple multi-stream QUIC client application which connects to a server, send
169 blocking QUIC client and the multi-stream QUIC client. Although the example code
174 The complete source code for this example multi-stream QUIC client is available
176 C<quic-multi-stream.c>. It is also available online at
177 L<https://github.com/openssl/openssl/blob/master/demos/guide/quic-multi-stream.c>.
179 =head2 Disabling the default stream
182 to disable the default stream for our multi-stream client. To do this we call
187 * We will use multiple streams so we will disable the default stream mode.
191 printf("Failed to disable the default stream mode\n");
199 first of these will be a bi-directional stream and the second one will be a
216 this example we will be sending a different HTTP request on each stream. To
218 request to a stream:
220 int write_a_request(SSL *stream, const char *request_start,
226 if (!SSL_write_ex(stream, request_start, strlen(request_start), &written))
228 if (!SSL_write_ex(stream, hostname, strlen(hostname), &written))
230 if (!SSL_write_ex(stream, request_end, strlen(request_end), &written))
243 order. For example we could start two threads (one for each stream) and write
244 the requests to each stream simultaneously.
248 printf("Failed to write HTTP request on stream 1\n");
253 printf("Failed to write HTTP request on stream 2\n");
257 =head2 Reading data from a stream
259 In this example B<stream1> is a bi-directional stream so, once we have sent the
262 either that there has been a problem, or that the peer has signalled the stream
267 * Get up to sizeof(buf) bytes of the response from stream 1 (which is a
268 * bidirectional stream). We keep reading until the server closes the
294 the stream is concluded and there will be no more data available to read from
295 it. Care must be taken to distinguish between an error at the stream level (i.e.
296 a stream reset) and an error at the connection level (i.e. a connection closed).
305 * QUIC terms this means that the peer has sent FIN on the stream to
310 /* Normal completion of the stream */
315 * Some stream fatal error occurred. This could be because of a stream
321 /* The stream has been reset but the connection is still healthy. */
330 printf("Unknown stream failure\n");
341 =head2 Accepting an incoming stream
343 Our B<stream2> object that we created above was a uni-directional stream so it
345 we assume that the server initiates a new stream to send us back the data that
347 blocking application this will wait indefinitely until the new stream has
353 * assume that the server will respond with a server initiated stream
354 * containing the data requested in our uni-directional stream. This doesn't
358 * We're using blocking mode so this will block until a stream becomes
364 printf("Failed to accept a new stream\n");
368 We can now read data from the stream in the same way that we did for B<stream1>
380 We should not call L<SSL_shutdown(3)> or L<SSL_shutdown_ex(3)> on the stream
