Hello,
I have a question regarding SSL_write() and returning SSL_ERROR_WANT_WRITE from the write callback. _After_ SSL_write() returns with SSL_ERROR_WANT_WRITE (because my write callback returned
SSL_ERROR_WANT_WRITE), can I _then_ send the data given to the calback and then call SSL_write() again (with the same arguments) and then in the second call to the callback return the number of bytes written? Is that a supported use of the API? (I'm asking because that's the only way I can use the API, I can't send the data inside the callback, I need to send it outside the callback, see below for why). In other words, is it guaranteed that on that second call to
SSL_write(), SSL will want to send the exact same data that it tried before when it failed, and not change its mind about it wants to send? Because technically, since SSL_ERROR_WANT_WRITE implies that "no data was sent", the state machine might as well advance and send something different at a later time (because it received data or something inside expired or whatever). ---- Why I need this: I'm using IOCP and LuaJIT which means I have two limitations: 1) Because I'm using a completion API as opposed to a readiness API, I can't just tell OpenSSL when the socket is writable and let it write to it, I need to write the data myself. 2) because LuaJIT doesn't allow me to yield from inside a C callback, I can't do async I/O inside the callback, I can only do it in between calls to SSL_read()/SSL_write(). Any suggestions appreciated, thanks! |
On Thu, Dec 10, 2020 at 05:14:00PM +0200, Cosmin Apreutesei wrote:
> Hello, > > I have a question regarding SSL_write() and returning SSL_ERROR_WANT_WRITE > from the write callback. > > _After_ SSL_write() returns with SSL_ERROR_WANT_WRITE (because my write > callback returned SSL_ERROR_WANT_WRITE), can I _then_ send the data given > to the calback and then call SSL_write() again (with the same arguments) > and then in the second call to the callback return the number of bytes > written? Is that a supported use of the API? (I'm asking because that's the > only way I can use the API, I can't send the data inside the callback, I > need to send it outside the callback, see below for why). > > In other words, is it guaranteed that on that second call to SSL_write(), > SSL will want to send the exact same data that it tried before when it > failed, and not change its mind about it wants to send? Because > technically, since SSL_ERROR_WANT_WRITE implies that "no data was sent", > the state machine might as well advance and send something different at a > later time (because it received data or something inside expired or > whatever). I don't fully understand your question, but the manpage says: WARNINGS When a write function call has to be repeated because SSL_get_error(3) returned SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE, it must be repeated with the same arguments. The data that was passed might have been partially processed. When SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER was set using SSL_CTX_set_mode(3) the pointer can be different, but the data and length should still be the same. Does that answer your question? Kurt |
In reply to this post by Cosmin Apreutesei
If you get SSL_ERROR_WANT_WRITE, call the same function with the same parameters and same buffer content immediately. (Same with SSL_ERROR_WANT_READ.) If you need to, stash those parameters in variables for ease of reference. But don't do anything else on the SSL layer until you get a different return value. (If you implement your own BIO layer, do what you need to do in support of what you're asked to do for the raw I/O. But don't do anything with the SSL layer until its internal state has moved past the need to read or write to or from the BIO.) -Kyle H On Thu, Dec 10, 2020, 09:14 Cosmin Apreutesei <[hidden email]> wrote:
|
Free forum by Nabble | Edit this page |