I am still curious whtehr there is a way to increase the timeout for the
connection handshake--possibly in registry. I won't implement session
caching because it is not realistic to assume same clients accessing the
server--you wrote that client and server both must support for session
caching. I want the worst case scenario. Let's think botnet of 1000 zombie
IE activeX's attacking our SSL proxy! (BTW, I have seen such attack with
HTTP on one of my servers. I know it was a botnet because 99% of the traffic
was from Turkey and Germany where Turkish population concentration is high
and the logs showed 99.99% GET / 's. Normally the domain was getting 20-30
hits per hour yet during the attack, it rose to 1200 connections/sec. I knew
who was behind it but had no proof. Had to pay for an attorney and suddenly
the attack was over in 6 days! He must have rented the botnet from a
malicious hacker team.)


On Fri, Mar 13, 2009 at 6:20 PM, Arno Garrels <arno.garr...@gmx.de> wrote:

> Fastream Technologies wrote:
> > I can see on my Vista x64 the reverse proxy drops SSL connections
> > with our web stress tester:
> I can produce plenty of "dropped" entries against the SslWebserver
> demo as well on both ports. The more clients and threads are setup
> in the testapp the more refused connections.
> That's the expected behaviour. Since SSL handshakes are rather
> expensive there is less load required until the first SSL connection
> is refused. And the testapp obviously does not support session caching.
> An option for session caching would be helpful in order to be able to
> compare.
> --
> Arno Garrels [TeamICS]
> http://www.overbyte.be/eng/overbyte/teamics.html
To unsubscribe or change your settings for TWSocket mailing list
please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be

Reply via email to