Lines Matching refs:which
21 mode, which is intended to provide compatibility with existing non-QUIC
44 The changes to existing libssl APIs which are driven by QUIC-related implementation
45 requirements, which existing applications should bear in mind;
49 Aspects which must be considered by existing applications when adopting QUIC,
50 including potential changes which may be needed.
74 When default stream mode is used, any API function which can be called on a QUIC
75 stream SSL object can also be called on a QUIC connection SSL object, in which
107 mode, in which no default stream is attached to the QUIC connection SSL object
119 with the connection, calls to API functions which are defined as operating on a
148 semantics, and is recommended for existing applications which use a BIO pair or
191 L<BIO_s_datagram(3)> when used with QUIC, therefore applications which use this
204 may not be suitable for short-lived processes which should exit immediately
224 L<SSL_net_write_desired(3)>. Only applications which wish to manage their own event
281 TLS Next Protocol Negotiation cannot be used and is superseded by ALPN, which
295 Some cipher suites which are generally available for TLSv1.3 are not available
333 Determine how to provide QUIC with network access. Determine which of the below
340 Your application uses L<BIO_s_socket(3)> to construct a BIO which is passed to
351 construct a BIO which is passed to the SSL object to provide it with network
373 L<BIO_s_dgram_pair(3)> instead, which has the necessary datagram semantics. You
420 If the SSL object is being used with an underlying network BIO which is pollable
423 resources which can be used to determine when L<SSL_handle_events(3)> should be
426 Applications which use thread assisted mode do not need to be concerned
469 which enables QUIC to achieve higher performance and more accurate connection
481 Applications which wish to implement QUIC-specific protocols should be aware of
482 the APIs listed under B<QUIC-SPECIFIC APIS> which provide access to
494 This section details new APIs which are directly or indirectly related to QUIC.
512 This is a non-specific I/O operation which makes a best effort attempt to
539 When an SSL object is being used with an underlying network read BIO which
540 supports polling, L<SSL_get_rpoll_descriptor(3)> outputs an OS resource which
541 can be used to synchronise on network readability events which should result in
586 This allows an application to determine the application error code which was
587 signalled by a peer which has performed a non-normal stream termination of the
592 This allows an application to determine the error code which was signalled when
605 Provides information on the kind of QUIC stream which is attached
610 Returns the QUIC stream ID which the QUIC protocol has associated with a QUIC
648 This is a new BIO method which is similar to a conventional BIO pair but
653 This is a new BIO API which allows a BIO to expose a poll descriptor. This API
659 This is a new BIO API which can be implemented by BIOs which implement datagram
667 to be enabled in which datagrams will not be silently truncated if they are
718 OpenSSL's QUIC implementation is designed to facilitate applications which wish
720 applications which wish to use the SSL APIs in a nonblocking fashion and manage
727 a structure which expresses some kind of OS resource which can be used to
733 Broadly, an application which wishes to manage its own event loop should
760 a L<BIO_s_datagram(3)>, or a custom BIO which implements
769 L<SSL_get_wpoll_descriptor(3)> to identify OS resources which can be used for
776 writability events on the underlying network BIO which was provided, and call
