On Mon, 1 Oct 2007, Darryl Miles wrote:

> Richard Salz wrote:
> > > double/triple check over it). Whatever fix you guys come up with, as 
> > long 
> > > as SSL_shutdown() ends up having sane (somehow aligned to SSL_read,
> > > SSL_write, etc...) semantics WRT non-blocking BIOs.
> > 
> > Nope.  Maybe a new shutdown that has your semantics, but do not break
> > existing code.
> 
> Great lets do that then have a SSL_shutdown2() based on my patch.
> 
> 
> Would Davide be so kind as to look over the following openssl-dev list post
> for the semantics I suggest and confirm that logic would work for him:
> 
> http://marc.info/?l=openssl-dev&m=115153998821797&w=2
> 
> 
> Maybe Davide could also try my PATCH2 and confirm that he can get sane working
> non-blocking semantics with the new behavior.  I think my patch is easier all
> around and does not introduce this new WANT_SHUTDOWN voodoo (which I think is
> unnecessary when I've been able to solve this problem in a way inline with the
> way OpenSSL is).

That is fine. The new WANT_SHUTDOWN can be removed w/out any problems. You 
could avoid changing ssl3_send_alert() too, and use s->s3->alert_dispatch 
as indicator of success, in case you want to minimize changes. Bu as I 
said, I don't care how it gets fixed.
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.




- Davide


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@openssl.org
Automated List Manager                           [EMAIL PROTECTED]

Reply via email to