IOCP / C10K

[Nick Mathewson]

On Wed, Mar 07, 2007 at 12:44:45PM -0000, Toby Douglass wrote:
> > On 3/7/07, Toby Douglass <toby.douglass at summerblue.net> wrote:
> >> I've written a C10K solution for Windows, libiocp.
> >> ...
> >> It is useful in its current form?
> >
> > this is useful for libevent.  unfortunately i am not volunteering a patch
> > :)
> 
> They know about it.  I've removed them from the CC:.  The problem is that
> the way libiocp is written is, as I understand it, not particularly
> compatable with the way libevent is written.  Merging the two is not an
> obvious proposition.  How focused is the Tor code on libevent?  is it only
> used for sockets?

Tor uses Libevent  sockets, signals, DNS, and the occasional timer.

The right thing to do when you need to support multiple IO frameworks
is usually to think of some abstraction that works with all of them,
implement that abstraction with all of them, and then write your other
code to use that abstraction.  To get IOCP used by Tor, the first step
is to find some abstraction that both IOCP and libevent can provide,
and then get Tor to use that abstraction for its network operations.

Right now, Tor uses libevent for networking stuff mainly for
notification of which sockets are readable and writable.  It seems
like IOCP is better at determining when reads and writes are done.
If this is the case, it seems way easier to use the event_base-based
functions in libevent to implement something like IOCP's interface
than to use IOCP to implement something like the event_base functions.

In fact, there's already a good candidate: IOCP looks like a closer
fit for libevent's bufferevent interface than for its regular
event_base interface.  (Bufferevent is currently written to assume
it's working using an existing event_base, but there's nothing
stopping somebody from putting a parallel implementation into place.)
If we can get better windows performance by using bufferevent, I bet
that would be the cleanest way to go about this.

Of course, this wouldn't be trivial work on Tor's side, and we might
need to extend the bufferevent interface to make it do what we need.
Still, this feels like the way forward to me.

yrs,
-- 
Nick Mathewson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 652 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20070307/039fdb98/attachment.pgp>