Sebastian Treu wrote: > 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. > [...]"
If you set ALLOW_MOVING_WRITE_BUFFER, the restriction is relaxed. The only restriction that remains is that you must present a consistent data stream. For example, if you try to SSL_write "foo" and two bytes are sent, your next SSL_write *must* start with an "o". > 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. Right. And you can either repeat forever or you can close the connection. What sensible servers do is call SSL_write once, get a want_whatever indication, and add the client to their 'select' or 'poll' set. If the client does nothing, the socket will never 'select', and the server will eventually timeout and close the client (or do whatever the protocol specifies, which may be to send something to the client). > 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. The warning is only within one specific SSL connection. It doesn't reach across SSL connections. > 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. I'm not sure I follow what you're saying here, but it sounds like you misunderstood the warning. In any event, set ACCEPT_MOVING_WRITE_BUFFER and then the only requirement is that you present a consistent picture of the byte stream to each SSL connection. > I want to be clear with this. Re-reading it I fall that maybe someone > could missunderstood it. What I wanted to say is that until the client > did not finish reading all the "chunk" of data, SSL_write() will keep > yielding WANT_WRITE. But, meanwhile we don't know how many data the > client has fetched. Imagine the client decides to read chunk of > Xbytes. Until the client did not read all the bytes that SSL_write() > writes, we'll get WANT_WRITE without any notions on how many bytes > have been read. So, in a given instant of time t0, we don't know if > the WANT_WRITE is actually a client reading by chunks less than we are > sending, or the client isn't reading at all. Right, but we don't care. We're the application, and the internals of the movement of SSL bytes is none of our business. Note that if you get WANT_WRITE, it means that no further progress has been made in application data bytes, which is all the application is allowed to care about. > There is where it should > appears select(). Am I wrong? Yes, you would add the client to your 'select' set so that you will know when to call SSL_write again. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
