ServerTCPWrite returing timeout error

[RadioAct]

I have a program that registers a TCP server and after some amount of time of working perfectly I am getting a TCPTimeOut error. Im just wondering what would cause this function to give a timeout error.

The only thing I could come up with is the client's TCP buffer is full and the server can't write anthing more to it. The client side uses the TCP callback to tell it when data is ready and it reads the data similar to the TCPclient example. However when the server gets a TCPTimeOut error, the client no longer gets TCP callbacks from the server. The interesting thing is that after the server gets the timout error, if the client writes data to the server the server gets the data but when it tries to write back to the client, it still gets the timeout error.

Anyone out there have any ideas?

Tyler

[RadioAct]

Ok I seem to have tracked down more of the source of this problem. it seems that the stack is being overrun and CVI can not execute anymore functions. After some time of running I get the following windows application error:

LWTCPJSOCKWNDYCLASS- exception (0xc00000fd) occurred in the application at location 0x684d15ec.
Some quick investigation indicates this is a stack overrun error.

My program calls PostDeferredCallToThread  to register events to different threads in the application and I believe that this is the cause of the problem.

First question: how big is the PostDeferredCallToThread queue?
Second: where does the data I pass to PostDeferredCallToThread to be passed to the callback get stored, the stack perhaps?

Thanks
Tyler

[RadioAct]

Ok, I think I have isolated the problem.

This problem is related to my other post about TCP Callbacks (http://forums.ni.com/ni/board/message?board.id=180&message.id=23147), it seems that the client stops servicing it rx buffer, the server eventually fills the windows TCP rx buffer on the remote computer, then the server fills the CVI TCP tx buffer on the localcomputer which overflows the stack. When I test the server with my hacked client, I no longer see the problem, the server does not overflow the stack.

I don't know much about how the CVI implements the TCP system but Im guessing that if I were to try to tx data to a client that was not servicing its rx buffer, the remote computer's TCP stack would buffer all it could then set the TCP recieve window to 0, the other side would keep trying to transmit and this eventually causes LWTCPJSOCKWNDYCLASS to overflow the stack.

If I find the time I will make a test app that is a client and server, have the client connect to the server but never service its rx buffer, and have the server send data to the client until it gets a TCP error code (a TCPWrite Error mabie?), ignore the error and keep sending and see if it will eventually overflow the stack.

Tyler