On Mon, 1 Oct 2007, Darryl Miles wrote: > Davide Libenzi wrote: > > Can this be worked around? Sure. With some woodoo/ugly magic code in the > > async status code handling. You *cannot* always wait for read&write, since > > you'll be exiting the event selection loop immediately, every time. > > You need to bolt-in the shutdown logic *outside* the shutdown API, and lever > > over the fact that it is internally composed by a write, followed by a read. > > And setup the waited I/O flags accordingly. > > If that's an example of "working API" for someone, it's no surprise > > websphere blows. > > Yes, I'm not sure I follow your workarounds/jargon completely, the possible > workarounds I can suggest would go something like this:
[...] There are many ways to do it, al of them require the "extraction" of the shutdown internal logic into the application. One of the simplest and system independent ways, is to wait for WRITE at most two times (given the notify-close packet size, and depends on the TCP stack implementation), and then wait only for READ the following times you get ERROR_SYSCALL. This, of course, only during the SSL_shutdown handling. You have those different case: 1) Write buffer space available - Peer notify-close packet not received In this case, our notify-close has been successfully queue by the TCP/IP stack, and the ERROR_SYSCALL is for a WANT_READ. This is the worst case, and you'll be wasting two (it could be one really, but two puts you on the safe side) cycles waiting for WRITE, while the following wait for READ will behave correctly. 2) Write buffer space available - Peer notify-close packet received This case is trivial, no ERROR_SYSCALL is issued. 3) Write buffer space not available - Peer notify-close packet not received In this case the first WRITE wait will bahave correctly. Then the following WRITE wait will be wasted, and the next READ will be ok. 4) Write buffer space not available - Peer notify-close packet received The first WRITE wait will block correctly. Then no more ERROR_SYSCALL will be issued. Or you can play with SIOCOUTQ, for systems that supports it. But whatever is the chosen method, that does not change the picture. That is, all this is butt-ugly, non conforming to the documentation, and non-coherent with the other OpenSSL APIs (SSL_read, SSL_write, ...). - Davide ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
