underlying BIO.
For the transparent negotiation to succeed, the B<ssl> must have been
-initialized to client or server mode. This is not the case if a generic
-method is being used (see L<SSL_CTX_new(3)|SSL_CTX_new(3)>, so that
+initialized to client or server mode. This is being done by calling
L<SSL_set_connect_state(3)|SSL_set_connect_state(3)> or SSL_set_accept_state()
-must be used before the first call to an L<SSL_read(3)|SSL_read(3)>
-or SSL_write() function.
+before the first call to an L<SSL_read(3)|SSL_read(3)> or SSL_write() function.
If the underlying BIO is B<blocking>, SSL_write() will only return, once the
write operation has been finished or an error occurred, except when a
B<SSL_ERROR_WANT_READ> or B<SSL_ERROR_WANT_WRITE>, it must be repeated
with the same arguments.
+When calling SSL_write() with num=0 bytes to be sent the behaviour is
+undefined.
+
=head1 RETURN VALUES
The following return values can occur:
The write operation was successful, the return value is the number of
bytes actually written to the TLS/SSL connection.
-=item 0
+=item Z<>0
+
+The write operation was not successful. Probably the underlying connection
+was closed. Call SSL_get_error() with the return value B<ret> to find out,
+whether an error occurred or the connection was shut down cleanly
+(SSL_ERROR_ZERO_RETURN).
-The write operation was not successful. Call SSL_get_error() with the return
-value B<ret> to find out, whether an error occurred.
+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.
=item E<lt>0