Darryl Miles <[email protected]> added the comment:
To explain why you need 2 modes, a client/server would expect to do the
following pseudo actions for maximum efficiency:
set_socket_timeout(600_SECONDS) # or useful default
send_data_over_ssl("QUIT\r\n")
shutdown(SSL_SHUTDOWN_MODE_SENT)
flush_data_down_to_socket() # maybe automatic/implied (OpenSSL users with
custom BIO layers should be aware of this step)
shutdown(socket, SHUT_WR) # this is optional, TCP socket level shutdown
recv_data_over_ssl() = "250 Bye bye!\r\n" # this will take time to arrive
set_socket_io_timeout(5_SECONDS)
shutdown(SSL_SHUTDOWN_MODE_BOTH) # this is optional! some clients may choose
to skip it entirely
close()/unwrap()
A server would:
recv_data_over_ssl() = "QUIT\r\n" # would be sitting idle waiting for this
command
send_data_over_ssl("250 Bye bye!\r\n")
shutdown(SSL_SHUTDOWN_MODE_SENT)
flush_data_down_to_socket() # maybe automatic/implied (OpenSSL users with
custom BIO layers should be aware of this step)
shutdown(socket, SHUT_WR) # this is optional, TCP socket level shutdown
set_socket_io_timeout(30_SECONDS)
shutdown(SSL_SHUTDOWN_MODE_BOTH) # a good server would implement this step
close()/unwrap()
Now if your outbound data is CORKed and flushed, the flush points would cause
all the SSL data from both the 'last sent data' and the 'send shutdown notify'
to go out in the same TCP segment and arrive at the other end more or less
together.
Doing any of the above in a different order introduces some kind of
inefficiency. shutdown(fd, SHUT_WR) are often used at the socket level to help
the manage TIME_WAIT.
The client has to wait for the QUIT response message anyway. With the above
sequence there is no additional time delay or cost with both parties performing
a SSL protocol shutdown at the same time. Despite the IO timeouts existing (to
provide a safety net).
If the client is talking to a buggy server the worst case scenario is that it
receives the quit response but the server never does an SSL shutdown and the
server doesn't close the socket connection. In this situation the client will
have to wait for IO timeout, some clients in other software use blocking
sockets and don't have a timeout so they end up hooked (forever).
----------
_______________________________________
Python tracker <[email protected]>
<http://bugs.python.org/issue8108>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
