Hi,
I'm currently testing a webservice on Windows Server 2008. The test program creates hundreds on concurrent threaded connections via 127.0.0.1 to the webservice in order to collect some performance metrics.
From the client side most of the connection are established, the SOAP data of the request is also successfully sent, however the connection fails with WSACONNRESET during recv().
From the webservice/server side logs I can see that a few connection are actually seen by the webservice. My understanding of the situation is that the underlying system accepts some connections in a system level stack that are terminated for whatever reason (timeout?) before the webservice has a chance to see that connection using the accept() system call.
The same test can be performed on Win XP and would yield different results. Indeed, under XP the client program would rather fail during the connect() call with a WSAECONNREFUSED but if the connect() succeeds then the SOAP call ends as expected.
Seems from my google searching that Windows Server implements some 'elaborate' TCP/IP security options beyond my knowledge that are not necessarily implemented on XP. For instance there is an option in Windows Server 2003, namely SynAttackProtect, that looks close to my problem but I could not test this platform however. And This option has been made obsolete in Windows Server 2008...
As far as I'm concerned (user of the Winsock C API) Win XP behaves the right way... I'd like to known if there is a way to make Windows Server 2008 behave like XP.
Thanks!