Lines Matching refs:peer
59 A close_notify shutdown alert message is sent to the peer.
63 A close_notify shutdown alert message is received from the peer.
68 shutdown process was first initiated by the local application or by the peer.
74 peer. The shutdown process will then be considered completed once the peer
78 read direction is closed by the peer. Once SSL_shutdown() is called,
80 until the peer decides to close the connection in turn. The peer might
89 If the peer was the first to initiate the shutdown process by sending a
93 return B<SSL_ERROR_ZERO_RETURN>), after all application data sent by the peer
103 Regardless of whether a shutdown was initiated locally or by the peer, if the
105 close_notify alert message is written to the peer (returning 0), and upon a
107 peer (returning 1 and completing the shutdown process). Calls to SSL_shutdown()
112 received from the peer, or because a close_notify alert message needs to be sent
125 peer's close_notify alert is still provided to the application. It also ensures
130 shutdown by confirming receipt of the peer's close_notify message) will fail if
132 sent by the peer using L<SSL_read(3)>.
145 waiting for the peer's response. This allows for a more rapid shutdown process
146 if the application does not wish to wait for the peer.
149 that the peer will not send more data, otherwise there is a risk of an
158 peer of connection shutdown.
181 application protocol in use enables the peer to ensure that all data has been
210 peer during calls to L<SSL_read(3)> by the application.
228 provide additional information to the peer on the reason why a connection is
235 An optional 62-bit application error code to be signalled to the peer. The value
241 An optional zero-terminated (UTF-8) reason string to be signalled to the peer.
264 to ensure that all transmitted data was received by the peer. This is unlike a
270 be received by the peer.
283 data written to a stream by an application has been acknowledged by the peer. In
285 application has been sent to the peer, and until the receipt of all such data is
286 acknowledged by the peer. Only once this process is completed is the shutdown
297 be transmitted to the peer. This flag may be used when a non-normal application
306 to ensure that any connection closure notification sent to the peer was
321 to three times the current estimated RTT to the peer. It is possible for the
332 In this mode, the peer is notified of connection closure on a best effort basis
333 by sending a single QUIC packet. If that QUIC packet is lost, the peer will not
353 peer rather than triggered locally. To do this, call SSL_shutdown_ex() with
355 waits until the peer initiates a shutdown or the connection otherwise becomes
363 stream data cannot be flushed after a peer closes the connection. Stream data
364 may still be sent to the peer in any time spent waiting before the peer closes
385 peer has not yet replied in turn with its own close_notify.
398 For TLS and DTLS, this means that a close_notify alert was sent and the peer's
