On Tue, Oct 06, 2015 at 02:37:32PM +0000, Plüm, Rüdiger, Vodafone Group wrote:
> The drawback is that it will flush every time the handshake writes.
> The handshake may write multiple times before it wants to read.
> So the current approach probably causes bigger amounts of data sent
> across the wire at once then the approach below and thus is more in line with
> the standard
> approach in httpd to avoid sending small chunks if not needed.
> So I would keep the current approach.
Looking at 1.0.1e, the state machine loop in ssl3_accept(), the coding
style is pretty clearly:
1. send something
2. flush
3. switch to new state.
e.g. like this....
ret=ssl3_send_hello_request(s);
if (ret <= 0) goto end;
s->s3->tmp.next_state=SSL3_ST_SW_HELLO_REQ_C;
s->state=SSL3_ST_SW_FLUSH;
...and then the SW_FLUSH mode switches to the tmp.next_state.
Hence In the server case, it seems reasonable to rely on BIO_flush()
being called at the "right" times during the handshake. Modulo the odd
bug!
But ssl/s3_clnt.c is not following that coding style at all, and it only
does a flush after completing the handshake. So I'd say the right thing
here is to FLUSH after every packet which comes through the write BIO
when the SSL state machine is in the middle of a "connect", i.e.
handshake as client.
tl;dr: I think Yann's patch should be right if the test is switched from
"always flush if !SSL_is_init_finished(ssl)" to "always flush if
SSL_in_connect_init(ssl)"???
Regards, Joe
