1

I've been having real difficulties getting a tcp connection to work with my web server. I think the issue might have something to do with the speed or ordering of the packets as the connection seems to start off managing okay then fails after a little while. I am running all this traffic through a program I've written and then over a serial line with the old SLIP protocol. I have found almost no info about how to make tcp connections SLOWER, seems like everyone else is trying to go the other way. How does one go about limiting the speed of a tcp connection? I think I'd need to turn down the amount each side tries to send at a time and how quickly they decide to resend.

Also does anyone know how i could lower the Window size on my windows 7 computer? (acting as the client trying to connect to the server) as i think this might help to slow things down. I've tried all of the registry values and they seem to have no effect, I've turned off scaling and heuristics but it still uses a window of 65500.

Here are some Wireshark captures from both the client and server side.

030
  • 5,901
  • 13
  • 68
  • 110
KGB
  • 11
  • 1

1 Answers1

2

I actually do quite a bit of testing of applications through high-latency situations due to the business I'm in... (we test with a variety of 200 - 1400ms latency links)

Typically, I would setup a linux router and use tc to emulate latency and packet loss (and such)... but in windows, I have never bothered to try. I did, however find something that may be useful for your environment...

http://jagt.github.io/clumsy/index.html

Apparently, you can add latency, jitter, duplicate packets, etc... to simulate whatever you're looking for.

... that being said... I seriously doubt that ordering/speed would cause serious issues with tcp-connectivity on a windows platform. The network stack in Windows is pretty robust against out-of-order or lost packets. Connections would be more likely to terminate due to lack of acks... or terminate due to inactivity. It is more likely that you're not letting windows maintain the TCP session... and instead have implemented your own ACKs/SYNs/etc... and haven't implemented a fail-safe timeout.

There are WAN optimization appliances out there that can cause issues where the TCP session is kept alive artificially, but the session has terminated. (Riverbeds, for example, can cause this.) These can become very complicated to troubleshoot... but from the bits I can gather from your packet-captures... it is unlikely that a riverbed is in-play here.

As a final note. Please don't rely on truncated pcaps. if using tcpdump don't forget to specify -s 0 to capture the WHOLE packet instead of just a abbreviated packet.

TheCompWiz
  • 7,409
  • 17
  • 23