Question

I'm building an application that uses TCP sockets to communicate. I want to test how it behaves under slow-speed conditions.

There are similar question on the site, but as I understand it, they deal with HTTP traffic, or are about Linux. My traffic is not HTTP, just ordinary TCP sockets, and the OS is Windows.

I tried using fiddler's setting for Modem Speed but it didn't work, it seems to work only for HTTP connections.

Was it helpful?

Solution

While it is true that you probably want to invest in an extensive set of unit tests, You can simulate various network conditions using VMWare Workstation:

Network Settings Screen

You will have to install a virtual machine for testing, setup bridged networking (for the vm to access your real network) and upload your code to the vm.

After that you can start changing the settings and see how your application performs.

NetLimiter can also be used, but it has fewer options (in your case, packet loss is very interesting to test and is not available in netlimiter).

OTHER TIPS

There is an excellent utility for Windows that can do throttling and much more:

https://jagt.github.io/clumsy/

I think you're taking the wrong approach here.

You can achieve everything that you need with some well designed unit tests. All of the things that a slow network link causes can be simulated in a unit test environment in controlled conditions.

Things that your code MUST handle to deal with "slow" links are just things that you should be dealing with anyway, including:

  • The correct handling of fragmented messages. All of your network reading code needs to correctly assume that each read will return between 1 byte and the size of your read buffer. You should never assume that you'll get complete 'messages' as TCP knows nothing of your concept of messages.
  • TCP flow control causing either your synchronous sends to fail with some form of 'try later' error or your async sends to succeed and potentially use an uncontrolled amount of resources (see here for more details). Note that this can happen even on 'fast' links if you are sending faster than the receiver is consuming.
  • Timeouts - again this isn't limited to "slow" links. All of your timeout handling code should be robust and tested. You may want to make sure that any read timeout is based on any read completing rather than reading a complete message in x time. You may be getting your data at a slow rate but whilst you're still getting data the link is alive.
  • Connection failure - again not something specific to "slow" links. You need to know how you deal with connections being reset at any time.

In summary nothing you can achieve by running your client and server on a simulated slow network cannot be achieved with a decent set of unit tests and everything that you would want to test on such a link is something that could affect any of your connections on any speed of link.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top