Issues with embedded server and windows 7

[psipro_1989]

Hello

I hope someone here will have suggestions for me. I have several small network attached data servers providing periodic UDP packets at constant rates (71 bytes at 10 Hz). The servers are connected 10 T and reside in a custom switch rack with a Gb uplink to a Cisco 2960G and from there to a Windows client. An active TCP socket must be maintained or the between the client and the server of the server will reset its internal application, stopping the data stream.

This configuration has run for years with a WinXP client but now with the requirement to change to Win7 I'm having problems.

With the client application running on Win7, one of the servers will intermittently stop responding to TCP ACKs and the client will (after the appropriate number of re-transmissions) send a fin packet. The server obligingly resets itself and announces its availability for connection.

The funny thing is that the application in the server continues to send UDP data even though the TCP keepalive ACKS are un acknowledged. It continues to believe that the connection is valid.

If the client application is run on a WinXP machine then the "disconnect" (due to missing keepalives) doesn't occur.

IP6 is disabled on all network hosts.

Question:

Is there something in Win7 (vs WinXP) that would cause a switch to stop transmitting TCP keepalive acks?

Has anyone experienced something similar, where a switch apparently stops transmitting TCP ACKs for a socket where keepalive ACK packets are the only traffic?

I also have one reported incidence of an HP Procurve involved in the same symptom at a different site. A reset (power off) of that switch resolved the issue and it has not reoccurred.

I feel as if this might be an ARP table issue in the switch but I can't think of how to test this theory. I don't have access to the Cisco or Procurve CLI and insufficient knowledge of the switch internals to be able to formulate a test case.

C.

 

[System Error Message]

you will need to change windows tcp options. By default windows is configured for slower networks and lesser networks. There are a number of tutorials online in changing the TCP options in windows and what each one does. in windows 7 this involves an administrator command prompt and some commands. You can also change this using the registry too.

 

[psipro_1989]

Which options? And what is the mechanism?

 

[System Error Message]

Using the command netsh interface tcp you can see various options and change them. netsh interface tcp show global will show what options you can change and to set it just use set.

 

[psipro_1989]

Yes, but which options are going to effect the situation? Without a clue about the actual mechanism behind the observed symptoms I'm reduced to simply "playing with" the settings. Yes, I'm familiar with, and have used, the netsh options to change the behavior of the network interface. I've set static ARP tables for some installations because the ARP refresh caused the high speed streams to get disconnected. This is different.

If you're going to be helpful its important to include some theory and a direction with your comments. Answering a question about types of security screws by indicating that a screwdriver can be found at Lowes is inane.

 

[System Error Message]

I am usually less inclined to spoon feed because i actually learnt to handle networking all by myself. I have before ask around and never got answers and if i had to research the answers for every question on various forums it would just take too much time.

http://www.icpdas.com/root/support/faq/card/software/FAQ_Disable_TCP_ACK_Delay_en.pdf provides a guide on changing the acknowledgement frequency and delays. By default in windows 7 this is reduced just to reduce traffic and interrupts. You can also disable interrupt moderation on your NIC as well.

 

[psipro_1989]

Off you'll review the op this is actually not relevant to the question. Thanks anyway.

 

[System Error Message]

if you look around the same registry area you can also modify TCP settings such as keepalive, timeouts and such. If you are using a custom application it might be better to use your own program to consistantly keep TCP connections alive.

If you use UDP dont expect to get an ACK reply.