Message257413
As I said in msg254389, the read/write handling for non-blocking
sockets is far from trivial.
I'm not sure that this is a Python bug:
Looking at dugong/__init__.py, I don't think this implements the
recommendations in the OpenSSL book that I mentioned.
The book recommends to keep a state ...
struct iostate {
int read_waiton_write;
int read_waiton_read;
int write_waiton_write;
int write_waiton_read;
int can_read;
int can_write;
};
... a check_availability() function that sets 'can_read', 'can_write'
... a write_allowed() function that determines whether a write is
even possible to attempt ...
int write_allowed(struct iostate *state)
{
if (state->read_waiton_write || state->read_waiton_read)
return 0;
if (state->can_write)
return 1;
if (state->can_read && state->write_waiton_read)
return 1;
return 0;
}
... and finally, the glorious loop:
while (!done) {
while (check_availability(ssl, &state) == -1 || !state.can_write)
nanosleep(&ts, NULL);
if (write_allowed(&state)) {
state.write_waiton_read = 0;
state.write_waiton_write = 0;
retval = SSL_write(ssl, wbuf, strlen(wbuf));
switch (SSL_get_error(ssl, retval)) {
case SSL_ERROR_NONE:
done = 1;
break;
case SSL_ERROR_ZERO_RETURN:
log_sslerr();
return -1;
break;
case SSL_ERROR_WANT_READ:
state.write_waiton_read = 1;
break;
case SSL_ERROR_WANT_WRITE:
state.write_waiton_write = 1;
break;
default:
log_sslerr();
break;
}
}
} |
|
Date |
User |
Action |
Args |
2016-01-03 13:08:40 | skrah | set | recipients:
+ skrah, janssen, pitrou, giampaolo.rodola, christian.heimes, alex, nikratio, dstufft |
2016-01-03 13:08:40 | skrah | set | messageid: <1451826520.67.0.229876233306.issue22499@psf.upfronthosting.co.za> |
2016-01-03 13:08:40 | skrah | link | issue22499 messages |
2016-01-03 13:08:40 | skrah | create | |
|