Lines Matching full:we
33 .\" If the F register is >0, we'll generate index entries on stderr for
70 blocking QUIC client. On this page we will amend that demo code so that it
78 As we saw in the previous example an OpenSSL QUIC application always uses a
97 \&\fBossl\-guide\-quic\-client\-block\fR\|(7) page we assume that you are familiar with it
98 and we only explain how this example differs.
102 we want to read or write to the \fBSSL\fR object but we are currently unable to.
117 In this demo application we will create a helper function which simulates doing
120 after which the state of the \fBSSL\fR object might have changed. We will call our
138 \& * Find out if we would like to write to the socket, or read from it (or
155 \& * Wait until the socket is writeable or readable. We use select here
181 application works. With a TLS application if we try to read or write something
182 to the \fBSSL\fR object and we get a "retry" response (\fBSSL_ERROR_WANT_READ\fR or
183 \&\fBSSL_ERROR_WANT_WRITE\fR) then we can assume that is because OpenSSL attempted to
191 socket for a QUIC application we must call the \fBSSL_net_read_desired\fR\|(3) and
194 It is also important with QUIC that we periodically call an I/O function (or
199 function can be used to determine what the deadline is for the next time we need
210 In this example we are using the \f(CW\*(C`select\*(C'\fR function to check the
222 has failed), or non-fatal (for example because we are trying to read from the
255 In our demo application we will write a function to handle these errors from
264 \& /* Temporary failure. Wait until we can read/write and try again */
300 \& * If the failure is due to a verification error we can get more
317 might succeed (by using the \f(CWwait_for_activity()\fR function that we developed
322 In order to connect to a server we must create \fBSSL_CTX\fR and \fBSSL\fR objects for
324 explained on the \fBossl\-guide\-quic\-client\-block\fR\|(7) page. We won't repeat that
327 One key difference is that we must put the \fBSSL\fR object into nonblocking mode
328 (the default is blocking mode). To do that we use the
334 \& * behaviour of the SSL object is still to block. We set it for nonblocking
343 Although the demo application that we are developing here does not use it, it is
354 this we must use \fBOSSL_QUIC_client_thread_method\fR\|(3) when we construct the
366 As in the demo for a blocking QUIC client we use the \fBSSL_connect\fR\|(3) function
367 to perform the handshake with the server. Since we are using a nonblocking
369 non-fatal error while we are waiting for the server to respond to our handshake
370 messages. In such a case we must retry the same \fBSSL_connect\fR\|(3) call at a
371 later time. In this demo we do this in a loop:
384 Otherwise we use the \f(CWhandle_io_failure()\fR function that we created earlier to
385 work out what we should do next. Note that we do not expect an EOF to occur at
389 As with the blocking QUIC client demo we use the \fBSSL_write_ex\fR\|(3) function to
390 send data to the server. As with \fBSSL_connect\fR\|(3) above, because we are using
392 that case we should retry exactly the same \fBSSL_write_ex\fR\|(3) call again. Note
400 details. As in the TLS tutorials (\fBossl\-guide\-tls\-client\-block\fR\|(7)) we write
403 First, we write the entire request to the stream. We also must make sure to
404 signal to the server that we have finished writing. This can be done by passing
406 \&\fBSSL_stream_conclude\fR\|(3). Since the first way is more efficient, we choose to
432 On a write we do not expect to see an EOF response so we treat that case in the
440 \& * Get up to sizeof(buf) bytes of the response. We keep reading until
458 \& * that it is NUL terminated so we use fwrite() to write the exact
459 \& * number of bytes that we read. The data could be non\-printable or
461 \& * we\*(Aqre going to print it to stdout anyway.
466 \& /* In case the response didn\*(Aqt finish with a newline we add one now */
474 In this demo we just print out all the data we've received back in the response
475 from the server. We continue going around the loop until we either encounter a
476 fatal error, or we receive an EOF (indicating a graceful finish).
479 As in the QUIC blocking example we must shutdown the connection when we are
482 Even though we have received EOF on the stream that we were reading from above,
487 Since our application is initiating the shutdown then we might expect to see
488 \&\fBSSL_shutdown\fR\|(3) give a return value of 0, and then we should continue to call
489 it until we receive a return value of 1 (meaning we have successfully completed
490 the shutdown). Since we are using a nonblocking \fBSSL\fR object we might expect to
492 negative result then we must call \fBSSL_get_error\fR\|(3) to work out what to do
493 next. We use our \fBhandle_io_failure()\fR function that we developed earlier for
510 blocking example, so we won't repeat it here.