busterb
commented
1 year ago That sounds odd on the surface! It might be helpful if there was an example showing this behavior. We're also almost 5 major release later, so the behavior may be different now. Any interest in giving some more details or a reproducer? I know it's been a while since this was filed.
Hi,
I'm using libtls in Windows with IOCP, so I have to use libtls callbacks and moreover, my programming environment (LuaJIT) is limited such that I cannot do the actual I/O operations from inside the libtls callbacks, I have to do it in between calls to tls_read() and tls_write().
To achieve that I return TLS_WANT_POLLIN and TLS_WANT_POLLOUT from the read/write callbacks respectively, then, when tls_read/tls_write returns with TLS_WANT_POLLIN/TLS_WANT_POLLOUT, I perform the I/O and then call tls_read/tls_write again with the exact same arguments as before, and expect the callbacks to be called again with the exact same arguments and this time the callbacks will return the byte sizes that were read/written.
The problem is that it appears that sometimes the second call to tls_write() causes it to change its mind about what it needs to send i.e. it calls the write callback with different arguments than last time when I returned TLS_WANT_POLLOUT. That doesn't work for me because even though last time I returned TLS_WANT_POLLOUT from the write callback, I actually did send that data. Of course given that TLS_WANT_POLLOUT implies "I haven't sent anything", libtls is free to assume that nothing was sent last time so it has the right to change its mind about what to send a second time.
The question is: is this behavior correct/normal/expected? Because if it is, this means that there's no way to use completion-based I/O and perform the I/O outside libtls's callbacks with the way the current API is designed.
Any suggestions appreciated, thanks.