Lines Matching full:we
19 blocking TLS client. On this page we will amend that demo code so that it
27 As we saw in the previous example a blocking socket is one which waits (blocks)
44 L<ossl-guide-tls-client-block(7)> page we assume that you are familiar with it
45 and we only explain how this example differs.
67 we want to read or write to the socket, but we are currently unable to. In fact
82 In this demo application we will create a helper function which simulates doing
86 We call our function C<wait_for_activity()> because all it does is wait until
102 * Wait until the socket is writeable or readable. We use select here
124 In this example we are using the C<select> function because it is very simple
130 while waiting for the socket state to change. But we don't use that timeout
138 connection has failed), or non-fatal (for example because we are trying to read
169 In our demo application we will write a function to handle these errors from
176 /* Temporary failure. Wait until we can read and try again */
181 /* Temporary failure. Wait until we can write and try again */
194 * If the failure is due to a verification error we can get more
210 might succeed (by using the C<wait_for_activity()> function that we developed
216 In order to connect to a server we must create B<SSL_CTX> and B<SSL> objects for
218 on the L<ossl-guide-tls-client-block(7)> page. We won't repeat that information
223 As in the demo for a blocking TLS client we use the L<SSL_connect(3)> function
224 to perform the TLS handshake with the server. Since we are using a nonblocking
226 error while we are waiting for the server to respond to our handshake messages.
227 In such a case we must retry the same L<SSL_connect(3)> call at a later time.
228 In this demo we this in a loop:
238 We continually call L<SSL_connect(3)> until it gives us a success response.
239 Otherwise we use the C<handle_io_failure()> function that we created earlier to
240 work out what we should do next. Note that we do not expect an EOF to occur at
245 As with the blocking TLS client demo we use the L<SSL_write_ex(3)> function to
246 send data to the server. As with L<SSL_connect(3)> above, because we are using
248 we should retry exactly the same L<SSL_write_ex(3)> call again. Note that the
256 blocking tutorial (L<ossl-guide-tls-client-block(7)>) we write the request
279 On a write we do not expect to see an EOF response so we treat that case in the
286 * Get up to sizeof(buf) bytes of the response. We keep reading until
304 * that it is NUL terminated so we use fwrite() to write the exact
305 * number of bytes that we read. The data could be non-printable or
307 * we're going to print it to stdout anyway.
312 /* In case the response didn't finish with a newline we add one now */
319 In this demo we just print out all the data we've received back in the response
320 from the server. We continue going around the loop until we either encounter a
321 fatal error, or we receive an EOF (indicating a graceful finish).
325 As in the TLS blocking example we must shutdown the connection when we are
328 If our application was initiating the shutdown then we would expect to see
329 L<SSL_shutdown(3)> give a return value of 0, and then we would continue to call
330 it until we received a return value of 1 (meaning we have successfully completed
331 the shutdown). In this particular example we don't expect SSL_shutdown() to
332 return 0 because we have already received EOF from the server indicating that it
333 has shutdown already. So we just keep calling it until SSL_shutdown() returns 1.
334 Since we are using a nonblocking socket we might expect to have to retry this
335 operation several times. If L<SSL_shutdown(3)> returns a negative result then we
336 must call L<SSL_get_error(3)> to work out what to do next. We use our
337 handle_io_failure() function that we developed earlier for this:
340 * The peer already shutdown gracefully (we know this because of the
341 * SSL_ERROR_ZERO_RETURN (i.e. EOF) above). We should do the same back.
347 * ret == 0 is unexpected here because that means "we've sent a
348 * close_notify and we're waiting for one back". But we already know
349 * we got one from the peer because of the SSL_ERROR_ZERO_RETURN
358 As with the blocking TLS client example, once our connection is finished with we
360 blocking example, so we won't repeat it here.