Lines Matching +full:application +full:- +full:specific

5 openssl-quic - OpenSSL QUIC
28 Default stream mode versus multi-stream mode for clients;
32 The changes to existing libssl APIs which are driven by QUIC-related
46 New, QUIC-specific APIs.
53 stream mode, which is intended to provide compatibility with existing non-QUIC
54 application usage patterns. In this mode, the connection has a single stream
57 client-initiated or server-initiated from a QUIC perspective depends on whether
62 instead adopt the multi-stream API. See the RECOMMENDATIONS FOR NEW APPLICATIONS
68 multi-stream mode. By default, a newly created QUIC connection SSL object uses
80 whether a stream is client-initiated or server-initiated. In default stream
81 mode, if a client application calls L<SSL_read(3)> first before any call to
82 L<SSL_write(3)> on the connection, it is assumed that the application protocol
83 is using a server-initiated stream, and the L<SSL_read(3)> call will not
86 application calls L<SSL_write(3)> before any call to L<SSL_read(3)> on the
87 connection, it is assumed that a client-initiated stream is to be used
91 New applications adopting QUIC should use multi-stream mode, described below,
98 using additional streams are strongly recommended to use multi-stream mode
105 =head2 Multi-Stream Mode
107 The recommended usage mode for new applications adopting QUIC is multi-stream
110 SSL object fail. Instead, an application calls L<SSL_new_stream(3)> or
112 receiving application data using L<SSL_read(3)> and L<SSL_write(3)>.
114 To use multi-stream mode, call L<SSL_set_default_stream_mode(3)> with an
119 When multi-stream mode is used, meaning that no default stream is associated
148 L<BIO_s_dgram_pair(3)> provides BIO pair-like functionality but with datagram
154 L<BIO_s_dgram_mem(3)> provides a simple memory BIO-like interface but with
159 An application may also choose to implement a custom BIO. The new
173 Traditionally, whether the application-level I/O APIs (such as L<SSL_read(3)>
177 application-level blocking mode using L<SSL_set_blocking_mode(3)>. See
182 Network-level I/O must always be performed in a nonblocking manner. The
183 application can still enjoy blocking semantics for calls to application-level
186 in nonblocking mode. For application-level blocking functionality, see
204 RFC-conformant QUIC shutdown process may take an extended amount of time. This
205 may not be suitable for short-lived processes which should exit immediately
226 loops need to use these functions; see B<APPLICATION-DRIVEN EVENT LOOPS> for
287 Post-Handshake Client Authentication is not available as QUIC prohibits its use.
297 for QUIC, such as B<TLS_AES_128_CCM_8_SHA256>. Your application may need to
307 but calls to the relevant functions are treated as no-ops:
328 A client application wishing to use QUIC must use L<OSSL_QUIC_client_method(3)>
335 A server application wishing to use QUIC must use L<OSSL_QUIC_server_method(3)>. 
341 apply for your application:
347 Your application uses L<BIO_s_socket(3)> to construct a BIO which is passed to
350 Changes needed: Change your application to use L<BIO_s_datagram(3)> instead when
353 address; see the B<QUIC-SPECIFIC APIS> section for details.
357 Your application uses L<BIO_new_ssl_connect(3)> to
366 Your application uses any other I/O strategy in this list but combines it with a
375 Your application uses a BIO pair to cause the SSL object to read and write
376 network traffic to a memory buffer. Your application manages the transmission
381 will need to modify your application to transmit and receive using a UDP socket
387 Your application uses a custom BIO method to provide the SSL object with network
390 Changes needed: The custom BIO must be re-architected to have datagram
401 An application must explicitly configure whether it wishes to use the SSL APIs
405 nonblocking network BIO, therefore the blocking mode at the application level
406 can be explicitly configured by the application using the new
407 L<SSL_set_blocking_mode(3)> API. The default mode is blocking. If an application
408 wishes to use the SSL object APIs at application level in a nonblocking manner,
413 If your client application does not choose to use thread assisted mode, it must
421 L<SSL_write(3)> regularly. If an application does not do this, it should ensure
428 (such as L<BIO_s_datagram(3)>), the application can use
442 QUIC stream to receive or provide application data, not to to determine if
447 Evaluate your application's use of L<SSL_shutdown(3)> in light of the changes
448 discussed in B<CHANGES TO EXISTING APIS>. Depending on whether your application
450 L<SSL_shutdown_ex(3)> API instead. See B<QUIC-SPECIFIC APIS> for details.
463 Whether the application will use blocking or nonblocking I/O at the application
466 If the application does nonblocking I/O at the application level it can choose
467 to manage its own polling and event loop; see B<APPLICATION-DRIVEN EVENT LOOPS>.
471 Whether the application intends to give the QUIC implementation direct access to
488 Applications which wish to implement QUIC-specific protocols should be aware of
489 the APIs listed under B<QUIC-SPECIFIC APIS> which provide access to
490 QUIC-specific functionality. For example, L<SSL_stream_conclude(3)> can be used
492 can be used to provide a QUIC application error code when closing a connection.
495 applications avoid use of the default stream mode and use the multi-stream API
499 =head1 QUIC-SPECIFIC APIS
519 This is a non-specific I/O operation which makes a best effort attempt to
532 The following SSL APIs are specific to QUIC:
540 in a protocol-agnostic manner.
543 client-only usage. The listener interface may expand to support additional
549 I<ssl>. See L<SSL_new_domain(3)> and L<openssl-quic-concurrency(7)> for details
591 detail in L<openssl-quic-concurrency(7)>.
604 Configures whether blocking semantics are used at the application level. This
638 This augments L<SSL_shutdown(3)> by allowing an application error code to be
639 specified. It also allows an application to decide how quickly it wants a
644 This allows an application to indicate the normal end of the sending part of a
650 This allows an application to indicate the non-normal termination of the sending
655 This allows an application to determine the current stream states for the
660 This allows an application to determine the application error code which was
661 signalled by a peer which has performed a non-normal stream termination of the
666 This allows an application to determine the error code which was signalled when
689 Creates a new QUIC stream SSL object representing a new, locally-initiated QUIC
695 remotely-initiated QUIC stream, blocking until one is available if the
700 Provides information on the number of pending remotely-initiated streams.
704 Configures how incoming, remotely-initiated streams are handled. The incoming
715 The following BIO APIs are not specific to QUIC but have been added to
716 facilitate QUIC-specific requirements and are closely associated with its use:
748 L<BIO_s_dgram_pair(3)>. In particular, this allows an application to inform the
776 application for a long time.
779 guarantees for the public SSL API are unchanged. Therefore, an application must
785 does provide the simplest mode of usage for an application.
790 =head1 APPLICATION-DRIVEN EVENT LOOPS
796 to host OpenSSL's QUIC implementation on top of an application's existing
807 Broadly, an application which wishes to manage its own event loop should
842 The application should call L<SSL_get_rpoll_descriptor(3)> and
883 the case of L<BIO_s_dgram_pair(3)>), the application is responsible for managing
888 call to L<BIO_sendmmsg(3)> and the application is responsible for ensuring these
891 The application must call L<SSL_get_event_timeout(3)> after every call to
917 Copyright 2022-2025 The OpenSSL Project Authors. All Rights Reserved.