Howdy,
First, thank you all for such a fantastic piece of software.
I've recently been exploring using async for our production mail servers.
We use the tls plugin, which I understand hasn't been re-written for the
async server yet.
First I tried the patch here:
http://www.nntp.perl.org/gro
Chris Babcock wrote:
Douglas Hunter wrote:
Howdy,
First, thank you all for such a fantastic piece of software.
I've recently been exploring using async for our production mail servers.
Why? Are you having issues with the other modes of operation?
Yes, there are too many concu
Matt Sergeant wrote:
On 1-May-08, at 5:20 PM, Chris Babcock wrote:
Async (at this point) is best suited to systems with very high
performance and concurrency requirements. If your system can run
without using async, the other modes are simpler to implement and
better tested.
On the other h
Chris Lewis wrote:
As a FYI, TLS with async is also an issue for us. I'll be testing your
patch on a VERY large spamtrap in the next little while.
Very cool. As I understand the code in IO::Socket::SSL::start_SSL, the
patch I provided forces blocking on the socket being upgraded, which
co
Charlie Brady wrote:
On Thu, 1 May 2008, Douglas Hunter wrote:
Yes, there are too many concurrent connections coming into our mail
server for the forkserver to handle given the iron it runs on, and
we're periodically bouncing mail.
Having more concurrent connections than your serve
Howdy all,
In the previous thread, I noticed that the socket upgrading that I had
hacked in defeated the purpose of TLS in -async, as it blocked while the
socket upgrade was in progress.
So I came up with a far uglier patch! [grin]
It borrows heavily from Perlbal::SocketSSL. The bad news i
Matt Sergeant wrote:
On 4-May-08, at 7:28 PM, Matt Sergeant wrote:
Yeah this makes a lot more sense... Though I wonder if we shouldn't
modify Danga::Client to just have some sort of "reader" entry, so that
anything else (not just TLS) can hook into the event_read stream. I'll
have a poke.
C
