Lines Matching full:we
33 .\" If the F register is >0, we'll generate index entries on stderr for
80 understanding of UDP/IP and sockets. The example code that we build in this
83 this one will be discussed so we also assume that you have run through and
96 In the TLS tutorial (\fBossl\-guide\-tls\-client\-block\fR\|(7)) we created an \fBSSL_CTX\fR
98 TLS connection. A QUIC connection works in exactly the same way. We first create
103 client. This is done in the same way as before except that we use a different
110 mode", see \fBossl\-guide\-quic\-introduction\fR\|(7)). For this tutorial we will be
111 using \fBOSSL_QUIC_client_method\fR\|(3) because we will not be leaving the QUIC
116 \& * Create an SSL_CTX which we can use to create SSL objects from. We
117 \& * want an SSL_CTX for creating clients so we use OSSL_QUIC_client_method()
127 The other setup steps that we applied to the \fBSSL_CTX\fR for TLS also apply to
128 QUIC except for restricting the TLS versions that we are willing to accept. The
140 example code is much the same as for TLS. We use the \fBBIO_lookup_ex\fR\|(3) and
141 \&\fBBIO_socket\fR\|(3) helper functions as we did in the previous tutorial except that
155 \& * we can connect to.
159 \& * Create a TCP socket. We could equally use non\-OpenSSL calls such
161 \& * functions. But for portability reasons and also so that we get
162 \& * errors on the OpenSSL stack in the event of a failure we use
194 \& /* Free the address information resources we allocated earlier */
199 that we used for TLS.
201 Firstly, we set the socket into nonblocking mode. This must always be done for
202 an OpenSSL QUIC application. This may be surprising considering that we are
207 Secondly, we take note of the IP address of the peer that we are connecting to.
208 We store that information away. We will need it later.
216 As for our TLS client, once the socket has been created and connected we need to
245 As in the TLS tutorial we need to set the server's hostname both for SNI (Server
257 simple client that we developed in \fBossl\-guide\-tls\-client\-block\fR\|(7) did not use
273 HTTP/1.0. We will use the same for this example. Unlike most OpenSSL functions
278 is being connected to. In "Creating the socket and BIO" above we saved that
279 address away for future use. Now we need to use it via the
290 Note that we will need to free the \fBpeer_addr\fR value that we allocated via
298 Once initial setup of the \fBSSL\fR object is complete then we perform the
299 handshake via \fBSSL_connect\fR\|(3) in exactly the same way as we did for the TLS
300 client, so we won't repeat it here.
303 automatically associated with the \fBSSL\fR object for us. We can transmit data
305 way as for TLS. The main difference is that we have to account for failures
310 First, we write the entire request to the stream. We also must make sure to
311 signal to the server that we have finished writing. This can be done by passing
313 \&\fBSSL_stream_conclude\fR\|(3). Since the first way is more efficient, we choose to
333 Then, we read the response from the server.
337 \& * Get up to sizeof(buf) bytes of the response. We keep reading until the
343 \& * that it is NUL terminated so we use fwrite() to write the exact
344 \& * number of bytes that we read. The data could be non\-printable or
346 \& * we\*(Aqre going to print it to stdout anyway.
350 \& /* In case the response didn\*(Aqt finish with a newline we add one now */
354 \& * Check whether we finished the while loop above normally or as the
356 \& * code we received from the SSL_read_ex() call. It must be 0 in order
396 fatal error. We can use \fBSSL_get_stream_read_state\fR\|(3) to determine whether the
400 In the TLS tutorial we knew that the server had finished sending data because
414 In this tutorial, once we have finished reading data from the server on the one
415 stream that we are using, we will close the connection down. As before we do
434 The shutdown process is in two stages. In the first stage we wait until all the
435 data we have buffered for sending on any stream has been successfully sent and
436 acknowledged by the peer, and then we send a CONNECTION_CLOSE to the peer to