[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [Libevent-users] OpenSSL-based bufferevents
On Tue, Mar 6, 2012 at 2:20 PM, Diwaker Gupta <diwaker@xxxxxxxxxxxxxx> wrote:
> I'm trying to figure out the best practice when it comes to OpenSSL
> based bufferevents. For reference, I'm looking at the source code as
> well as http://www.wangafu.net/~nickm/libevent-book/Ref6a_advanced_bufferevents.html
>
> As background, I have a fairly stable transport layer implemented
> using regular bufferevents. I'm now planning to add SSL support to the
> transport. The other end in my case is implemented in Java, if that
> matters.
>
> Questions:
>
> * Should I be using socket-based or filter-based bufferevent? A
> comment in the code seems to indicate that the former might be faster
> on all platforms except Windows. What kind of performance difference
> are we talking about here? In terms of abstractions, I like the latter
> because I can then think in terms of a chain of filtered bufferevents.
I haven't measured the performance difference, but I suspect it's
real. The filtering case involves another layer of buffering,
copying, and callbacks, and those typically matter. Then again, it
could be that crypto dominates the performance. In either case,
there's less machinery to go wrong in the non-filtering case.
> * How stable is the OpenSSL support in bufferevents? I just hacked up
> a quick prototype where I create a filter bufferevent on top of my
> existing bufferevent and I'm seeing all kinds of strange behavior.
> Specifically, I'm seeing deadlock-like hangs (will file a proper bug
> report with stack traces later). Note that I'm using libevent with
> thread support, bufferevents with OPT_THREADSAFE, DEFERRED_CALLBACKS
> and UNLOCK_CALLBACKS.
If you're doing this in multithreaded mode, you might be running into
this issue:
http://archives.seul.org/libevent/users/Feb-2012/msg00053.html
We'd sure like to fix it; any comments on that thread would be great!
> * When using a filtered bufferevent, should the filter be created
> AFTER the original bufferevent has successfully established
> connection? This works for me but if I create the filter immediately
> and then call bufferevent_socket_connect_hostname, I never get the
> event callback.
Sounds like that could be a bug; are you calling connect on the filter
or the underlying bufferevent?
--
Nick
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users in the body.