Re: [Libevent-users] How to set "allow_dirty_shutdown" for SSL?

[Nick Mathewson <nickm@xxxxxxxxxxxxx>]

On Tue, Jan 12, 2010 at 11:00 AM, Joachim Bauch <jojo@xxxxxxxxxxx> wrote:
> Hi,
>
> Nick Mathewson wrote:
   [...]
>> On the other hand, there should be _some_ way of detecting and
>> reporting a dirty shutdown more detectable.  Instead of having an
>> allow_dirty_shutdown flag, maybe there should be a got_dirty_shutdown
>> flag that the user can check when getting an SSL error.  (There
>> doesn't seem to be a particular OpenSSL error that gets set in this
>> case, so I don't expect that calling bufferevent_get_openssl_error
>> would do any good.)
>
> Okay, understood. My problem is, that for some clients the TCP
> connection is closed without the SSL-close protocol being performed
> beforehand. This is not really an error in my use case, but I can't
> differentiate between this dirty shutdown and a regular error - both
> events are reported as "BEV_EVENT_ERROR" to my app.
>
> My application-level callback is not triggered from "conn_closed()"
> as Jardel wrote, but from "be_openssl_eventcb" (my SSL bufferevent is
> wrapped around a regular bufferevent).
>
> To report a dirty shutdown, I suggest passing an event of
> "BEV_EVENT_ERROR|BEV_EVENT_EOF" to the application (instead of the
> "BEV_EVENT_ERROR" as is now), so the dirty shutdown can be detected
> and handled differentely to the clean shutdown (which is "BEV_EVENT_EOF"
> only).
>
> Any objections or should I prepare a patch for this?

I think that's a suboptimal interface.  The events argument to eventcb
is a bitfield of different events, so if we use ERROR|EOF to mean a
dirty shutdown, we won't be able to tell it from an error and an eof
both being reported at once.

There _is_ a mechanism to distinguish OpenSSL errors from one another
from eventcb: bufferevent_get_openssl_error().   The only problem is
that a closed connection is not necessarily reported by openssl as an
openssl error.  I wonder if we can find some unused part of the
openssl error space to reserve for libevent.
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.