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.) Regards,
SZ On Fri, Mar 13, 2009 at 6:20 PM, Arno Garrels <[email protected]> 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
