Lines Matching full:we
19 blocking QUIC client. On this page we will amend that demo code so that it
27 As we saw in the previous example an OpenSSL QUIC application always uses a
40 We will see later in this tutorial how to change the B<SSL> object so that it
46 L<ossl-guide-quic-client-block(7)> page we assume that you are familiar with it
47 and we only explain how this example differs.
52 we want to read or write to the B<SSL> object but we are currently unable to.
67 In this demo application we will create a helper function which simulates doing
70 after which the state of the B<SSL> object might have changed. We will call our
87 * Find out if we would like to write to the socket, or read from it (or
104 * Wait until the socket is writeable or readable. We use select here
129 application works. With a TLS application if we try to read or write something
130 to the B<SSL> object and we get a "retry" response (B<SSL_ERROR_WANT_READ> or
131 B<SSL_ERROR_WANT_WRITE>) then we can assume that is because OpenSSL attempted to
139 socket for a QUIC application we must call the L<SSL_net_read_desired(3)> and
142 It is also important with QUIC that we periodically call an I/O function (or
147 function can be used to determine what the deadline is for the next time we need
158 In this example we are using the C<select> function to check the
171 has failed), or non-fatal (for example because we are trying to read from the
204 In our demo application we will write a function to handle these errors from
212 /* Temporary failure. Wait until we can read/write and try again */
248 * If the failure is due to a verification error we can get more
264 might succeed (by using the C<wait_for_activity()> function that we developed
270 In order to connect to a server we must create B<SSL_CTX> and B<SSL> objects for
272 explained on the L<ossl-guide-quic-client-block(7)> page. We won't repeat that
275 One key difference is that we must put the B<SSL> object into nonblocking mode
276 (the default is blocking mode). To do that we use the
281 * behaviour of the SSL object is still to block. We set it for nonblocking
289 Although the demo application that we are developing here does not use it, it is
300 this we must use L<OSSL_QUIC_client_thread_method(3)> when we construct the
311 As in the demo for a blocking QUIC client we use the L<SSL_connect(3)> function
312 to perform the handshake with the server. Since we are using a nonblocking
314 non-fatal error while we are waiting for the server to respond to our handshake
315 messages. In such a case we must retry the same L<SSL_connect(3)> call at a
316 later time. In this demo we do this in a loop:
326 We continually call L<SSL_connect(3)> until it gives us a success response.
327 Otherwise we use the C<handle_io_failure()> function that we created earlier to
328 work out what we should do next. Note that we do not expect an EOF to occur at
333 As with the blocking QUIC client demo we use the L<SSL_write_ex(3)> function to
334 send data to the server. As with L<SSL_connect(3)> above, because we are using
336 that case we should retry exactly the same L<SSL_write_ex(3)> call again. Note
344 details. As in the TLS tutorials (L<ossl-guide-tls-client-block(7)>) we write
347 First, we write the entire request to the stream. We also must make sure to
348 signal to the server that we have finished writing. This can be done by passing
350 L<SSL_stream_conclude(3)>. Since the first way is more efficient, we choose to
374 On a write we do not expect to see an EOF response so we treat that case in the
381 * Get up to sizeof(buf) bytes of the response. We keep reading until
399 * that it is NUL terminated so we use fwrite() to write the exact
400 * number of bytes that we read. The data could be non-printable or
402 * we're going to print it to stdout anyway.
407 /* In case the response didn't finish with a newline we add one now */
414 In this demo we just print out all the data we've received back in the response
415 from the server. We continue going around the loop until we either encounter a
416 fatal error, or we receive an EOF (indicating a graceful finish).
420 As in the QUIC blocking example we must shutdown the connection when we are
423 Even though we have received EOF on the stream that we were reading from above,
428 Since our application is initiating the shutdown then we might expect to see
429 L<SSL_shutdown(3)> give a return value of 0, and then we should continue to call
430 it until we receive a return value of 1 (meaning we have successfully completed
431 the shutdown). Since we are using a nonblocking B<SSL> object we might expect to
433 negative result then we must call L<SSL_get_error(3)> to work out what to do
434 next. We use our handle_io_failure() function that we developed earlier for
449 we must free it. The steps to do this for this example are the same as for the
450 blocking example, so we won't repeat it here.