httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dean gaudet <>
Subject Re: mod_socks5
Date Sun, 11 Jun 2000 10:02:08 GMT
On 5 Jun 2000, Sam Magnuson wrote:

> I thought I would share this with the Apache group as it may be of some
> small interest. Aventail has been doing some plans for a next generation of
> our socks server, there has been some discussion how best to approach it
> and Apache 2.0 came up. We in turn hacked up a mod_socks5 which turns Apache
> into a socks5 server. And as kudos to ASF it works exceedingly well - there
> were some problems as they relate to speed comparisons of Apache to our
> existing Socks server. It still is very unclear why it performs so much
> worse under these circumstances. 

nice to see folks using the code this way :)

> I'm mostly sharing the code, and don't have much hope of answering why
> exactly we didn't see the performance gains we were expecting (as well as
> some odd socket fu) - but if anyone going over it comes up with something I
> would certainly be very interested in hearing it.

have you looked at a system call trace yet?

> Anyone still interested in the module at this point can look at
> this implementation uses some hackiness to accomplish the polling on both
> the client and server side. This could be some of the source of oddness I
> was seeing, and will probably need to be something fixed for mod_proxy to
> work (in the connect case we need similar behaviour).

yeah that certainly is some hacky code :)

you know that your hacky_poll_on_bufs code can block both directions if
one of the client or server isn't keeping up with its input?  i.e. A sends
64k to B, and there's only 32K buffer space in B, so one of the
ap_s5_safe_writes will block -- so B won't be able to send anything to A
until B clears its buffer.  (it's a common problem in lot of proxy code
i've looked at, and i'm pretty sure it's a problem with the existing
socks5 server.)

the full solution requires more sophisticated buffering... and fully
asynchronous coding.  the asynch stuff becomes difficult when layered i/o
is added to the picture.  i've been wrestling with this for a while trying
to come up with the right abstraction for asynchronous callbacks with
layered i/o stacks.  (for a proxy which has to speak three different
transports -- TCP, SSL, and simon spero's SCP).

i'm not really sure how to cleanly combine both styles of i/o in the same


View raw message