.\" -*- mode: troff; coding: utf-8 -*-
.\" Automatically generated by Pod::Man 5.01 (Pod::Simple 3.43)
.\"
.\" Standard preamble:
.\" ========================================================================
.de Sp \" Vertical space (when we can't use .PP)
.if t .sp .5v
.if n .sp
..
.de Vb \" Begin verbatim text
.ft CW
.nf
.ne \\$1
..
.de Ve \" End verbatim text
.ft R
.fi
..
.\" \*(C` and \*(C' are quotes in nroff, nothing in troff, for use with C<>.
.ie n \{\
.    ds C` ""
.    ds C' ""
'br\}
.el\{\
.    ds C`
.    ds C'
'br\}
.\"
.\" Escape single quotes in literal strings from groff's Unicode transform.
.ie \n(.g .ds Aq \(aq
.el       .ds Aq '
.\"
.\" If the F register is >0, we'll generate index entries on stderr for
.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
.\" entries marked with X<> in POD.  Of course, you'll have to process the
.\" output yourself in some meaningful fashion.
.\"
.\" Avoid warning from groff about undefined register 'F'.
.de IX
..
.nr rF 0
.if \n(.g .if rF .nr rF 1
.if (\n(rF:(\n(.g==0)) \{\
.    if \nF \{\
.        de IX
.        tm Index:\\$1\t\\n%\t"\\$2"
..
.        if !\nF==2 \{\
.            nr % 0
.            nr F 2
.        \}
.    \}
.\}
.rr rF
.\" ========================================================================
.\"
.IX Title "SSL_write 3"
.TH SSL_write 3 2019-12-20 1.0.2u OpenSSL
.\" For nroff, turn off justification.  Always turn off hyphenation; it makes
.\" way too many mistakes in technical documents.
.if n .ad l
.nh
.SH NAME
SSL_write \- write bytes to a TLS/SSL connection.
.SH SYNOPSIS
.IX Header "SYNOPSIS"
.Vb 1
\& #include <openssl/ssl.h>
\&
\& int SSL_write(SSL *ssl, const void *buf, int num);
.Ve
.SH DESCRIPTION
.IX Header "DESCRIPTION"
\&\fBSSL_write()\fR writes \fBnum\fR bytes from the buffer \fBbuf\fR into the specified
\&\fBssl\fR connection.
.SH NOTES
.IX Header "NOTES"
If necessary, \fBSSL_write()\fR will negotiate a TLS/SSL session, if
not already explicitly performed by \fBSSL_connect\fR\|(3) or
\&\fBSSL_accept\fR\|(3). If the
peer requests a re-negotiation, it will be performed transparently during
the \fBSSL_write()\fR operation. The behaviour of \fBSSL_write()\fR depends on the
underlying BIO.
.PP
For the transparent negotiation to succeed, the \fBssl\fR must have been
initialized to client or server mode. This is being done by calling
\&\fBSSL_set_connect_state\fR\|(3) or \fBSSL_set_accept_state()\fR
before the first call to an \fBSSL_read\fR\|(3) or \fBSSL_write()\fR function.
.PP
If the underlying BIO is \fBblocking\fR, \fBSSL_write()\fR will only return, once the
write operation has been finished or an error occurred, except when a
renegotiation take place, in which case a SSL_ERROR_WANT_READ may occur. 
This behaviour can be controlled with the SSL_MODE_AUTO_RETRY flag of the
\&\fBSSL_CTX_set_mode\fR\|(3) call.
.PP
If the underlying BIO is \fBnon-blocking\fR, \fBSSL_write()\fR will also return,
when the underlying BIO could not satisfy the needs of \fBSSL_write()\fR
to continue the operation. In this case a call to
\&\fBSSL_get_error\fR\|(3) with the
return value of \fBSSL_write()\fR will yield \fBSSL_ERROR_WANT_READ\fR or
\&\fBSSL_ERROR_WANT_WRITE\fR. As at any time a re-negotiation is possible, a
call to \fBSSL_write()\fR can also cause read operations! The calling process
then must repeat the call after taking appropriate action to satisfy the
needs of \fBSSL_write()\fR. The action depends on the underlying BIO. When using a
non-blocking socket, nothing is to be done, but \fBselect()\fR can be used to check
for the required condition. When using a buffering BIO, like a BIO pair, data
must be written into or retrieved out of the BIO before being able to continue.
.PP
\&\fBSSL_write()\fR will only return with success, when the complete contents
of \fBbuf\fR of length \fBnum\fR has been written. This default behaviour
can be changed with the SSL_MODE_ENABLE_PARTIAL_WRITE option of
\&\fBSSL_CTX_set_mode\fR\|(3). When this flag is set,
\&\fBSSL_write()\fR will also return with success, when a partial write has been
successfully completed. In this case the \fBSSL_write()\fR operation is considered
completed. The bytes are sent and a new \fBSSL_write()\fR operation with a new
buffer (with the already sent bytes removed) must be started.
A partial write is performed with the size of a message block, which is
16kB for SSLv3/TLSv1.
.SH WARNING
.IX Header "WARNING"
When an \fBSSL_write()\fR operation has to be repeated because of
\&\fBSSL_ERROR_WANT_READ\fR or \fBSSL_ERROR_WANT_WRITE\fR, it must be repeated
with the same arguments.
.PP
When calling \fBSSL_write()\fR with num=0 bytes to be sent the behaviour is
undefined.
.SH "RETURN VALUES"
.IX Header "RETURN VALUES"
The following return values can occur:
.IP "> 0" 4
.IX Item "> 0"
The write operation was successful, the return value is the number of
bytes actually written to the TLS/SSL connection.
.IP "<= 0" 4
.IX Item "<= 0"
The write operation was not successful, because either the connection was
closed, an error occurred or action must be taken by the calling process.
Call \fBSSL_get_error()\fR with the return value \fBret\fR to find out the reason.
.Sp
SSLv2 (deprecated) does not support a shutdown alert protocol, so it can
only be detected, whether the underlying connection was closed. It cannot
be checked, why the closure happened.
.Sp
Old documentation indicated a difference between 0 and \-1, and that \-1 was
retryable.
You should instead call \fBSSL_get_error()\fR to find out if it's retryable.
.SH "SEE ALSO"
.IX Header "SEE ALSO"
\&\fBSSL_get_error\fR\|(3), \fBSSL_read\fR\|(3),
\&\fBSSL_CTX_set_mode\fR\|(3), \fBSSL_CTX_new\fR\|(3),
\&\fBSSL_connect\fR\|(3), \fBSSL_accept\fR\|(3)
\&\fBSSL_set_connect_state\fR\|(3),
\&\fBssl\fR\|(3), \fBbio\fR\|(3)