[Libevent-users] Stunt Buffering: re-processing pipelined read data after filter insertion

[Dave Cridland <dave@xxxxxxxxxxxx>]

Folks,

I'm using libevent in my project Metre: https://github.com/dwd/Metre

Metre deals with XMPP, which is a starttls-style protocol (sometimes).
I would like to handle the case where a peer server sends the
<stream:stream> open, the <starttls/>, and the TLS ClientHello all in
the same packet. (I would prefer not to start a holy war on whether
this is a good idea or not - let's just say it's very good in some
obscure cases, and bad in others).

I'm currently handling the <starttls/> in a fairly normal way - I
insert a bufferevent_openssl_filter prior to negotiation commencing.
But this means that data received after the <starttls/> command is
received, and prior to the filter insertion, remains unhandled by the
filter (and instead is passed through to the application). For obvious
reasons this doesn't end well. Compounding this issue is a need to go
hunting through DNS between the peer sending me <starttls/> and my
initiating the negotiation (by sending the peer <proceed/>).

(Code is at https://github.com/dwd/Metre/blob/master/src/starttls.cc
should you need a good laugh).

So:

1) I can't conceive a case where unhandled data in the read buffer of
a bufferevent should not be reprocessed by a newly inserted filter. So
I think this is a bug (or missing feature, or something). Loosely, I
think that inside bufferevent_filter_new(), it should:

if (input_buffer_is_not_empty) {
  call_input_callback();
}

2) It'd be great to workaround the bug (or missing feature, or deal
with my unique insanity, or whatever). Is there any way I can coerce
libevent into reprocessing that data into the new filter? (Faking a
socket read would be fine). I imagine I could handle this by including
a bufferevent pair somewhere, but that seems hideous and inefficient.

Any pointers gratefully received.

Dave.
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.