Hi David,
>> Others things are to instantaneously put that client in a wait list
>> when SSL_write() could not succed, continue with the others, and try
>> with that client again later. But, sometimes we can get a WANT_WRITE
>> or WANT_READ when renegotiating so this does not appears a solution.
>
> I don't follow. Why is that not a solution?
Well, maybe I miss the point of what man pages wanted to say with:
"[...]
WARNING
When an SSL_write() operation has to be repeated because of
SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE, it must be repeated with
the same arguments.
[...]"
It's confusing for me. I know it doesn't make sense that if we
SSL_write() to a client that doesn't read, repeating SSL_write() with
same arguments will yield want_read and want_write all the time. What
exactly that means then? That's why I made a design on threads per
client (and the server will manage less than 20 connections for sure)
taking into account that "warning" from the man pages. So, I discarted
the solution of SSL_write() on another SSL structure when we get
want_read or want_write because I will be calling the function with
differents arguments. I also noted that SSL_write() is "clever" enough
to send _any_ length, so segmented writes will be overriding that
warning (if I undestood what man wanted to say). When I say clever
enough, I meant that in what I have proven (e.g. sending a 3mb file)
SSL_write() sends it by it's own (yielding want_write until it finish
with buffered data). The main reason the solution was discarted is
because that warning on man pages.
Regards,
--
If you want freedom, compile the source. Get gentoo.
Sebastián Treu
http://labombiya.com.ar
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
