WSI server socket timeout

[cknittel]

Hi,

My application (Windows, VA 7.5) is running an XML WSI server. Processing of some XML requests can take very long.

Now if processing takes more than 120 seconds, it seems that the connection is dropped due to some timeout. The client application then gets the socket error 10054 ("Connection reset by peer").

While AbtXmlConnectionTcp>>#socketTimeout: allows me to specify a timeout, this timeout applies to receiving the request data, not returning the response data. (BTW, I also had to increase this setting from the default value of 5000 because that value is in microseconds, not milliseconds, and therefore much too small.)

How can I increase the response timeout?

Thanks and best regards,
Christoph

[marten]

Hi,

My application (Windows, VA 7.5) is running an XML WSI server. Processing of some XML requests can take very long.

Now if processing takes more than 120 seconds, it seems that the connection is dropped due to some timeout. The client application then gets the socket error 10054 ("Connection reset by peer").

* Does this also happen in a local network (without routers).
* Just a very strange idea - are you sure, that the port is NOT closed (more or less at once after receiving the request) by the Smalltalk application ? Perhaps you should look at all "close" messages send to the socket stream !?

Marten

[cknittel]

Hi Marten,

Yes, it happens in a local network. It even happens when the server and the client application run on the same machine.

I am sure that the port is not closed immediately because everything works fine for processing times < 120 seconds.

Best regards,
Christoph

[marten]

Hi Marten,

Yes, it happens in a local network. It even happens when the server and the client application run on the same machine.

I am sure that the port is not closed immediately because everything works fine for processing times < 120 seconds.

Best regards,
Christoph

On the other hand you may set the send timeout (via socket options - look at the SciSocketConstants::SOSNDTIMEO ), but I would not understand, why this parameter has any influence on that behaviour.

When googling 120 seconds mostly a typical behaviour is found: the server application has closed the socket and due to some parameters the system waits with actually closing for around 120 seconds (linger and FIN_WAIT - or however this is called).

[cknittel]

Thanks! You gave me the right clue with FIN_WAIT!

I am not a socket programming expert, but after some googling I believe that the following happens (see also http://support.microsoft.com/kb/137984):

1.) The (non-Smalltalk) client connects to the WSI server and sends the XML request.

2.) Then it closes the sending half of its connection immediately and therefore the client socket goes into the FIN_WAIT_2 state.

3.) The server socket goes into the CLOSE_WAIT state.

4.) When the server still hasn't finished processing the request after 120 seconds, some timeout is reached and the connection is reset by the Windows TCP stack.

According to http://support.microsoft.com/kb/923200, the timeout for the FIN_WAIT_2 state can be changed in the registry (at least in Windows Server 2003), but on my XP machine this had no effect.

I'll do some further research...

[cknittel]

According to http://support.microsoft.com/kb/923200, the timeout for the FIN_WAIT_2 state can be changed in the registry (at least in Windows Server 2003), but on my XP machine this had no effect.

Actually I just needed to reboot it...

To summarize:

The timeout can be controlled on the client side by setting the DWORD value

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\TCPFinWait2Delay

in the registry. The range for this value is from 30 through 300, and the default value seems to be 120 on Windows XP.

[marten]

2.) Then it closes the sending half of its connection immediately

I do not understand this point ...

[cknittel]

2.) Then it closes the sending half of its connection immediately

I do not understand this point ...

I'll try to be more precise. See the state diagram at http://tangentsoft.net/wskfaq/articles/debugging-tcp.html.

* Client sends FIN and receives ACK.
* Client is now in FIN_WAIT_2 state.
* Server is now in CLOSE_WAIT state.
* Server does not send FIN until processing is complete.
* Client TCP stack resets the connection after TCPFinWait2Delay seconds.

[marten]

Thanks for the explanation - I've to think about this style of socket programming - a wrong registry entry at the client and you get very
easily ip problems everywhere and changing the registry for a single
program ... to make it work.