3

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.

sashoalm
  • 75,001
  • 122
  • 434
  • 781
  • You're looking for a traffic shaper. Fiddler acts as a HTTP proxy, that's why it doesn't work across the board. A quick google reveals [NetLimiter](http://www.netlimiter.com), never used it, can't say anything about it's capabilities. Not really a programming question (probably best for superuser). – Anya Shenanigans Nov 14 '13 at 14:57
  • Thanks, but just to forestall any off-topic close votes, StackOverflow allows questions about tools specifically used by programmers, like IDEs and such, I think it's written in the [FAQ] somewhere. – sashoalm Nov 14 '13 at 14:59
  • 1
    You cannot easily simulate this. What you _can do_ is configure Policy-based QoS to throttle down your network traffic, and what you can do is drop packets at the driver level and advertize a small window. This can simulate real-world rate limiting such as in a datacenter where you have a so-called 100MBit link which is really a 1Gbit link going into a switch that is configured accordingly, and it can simulate packet loss. But the packets that do come in still come in at normal speed. You're at best getting an "average" slow speed. – Damon Nov 14 '13 at 16:16
  • Using the group policy editor, under "computer config" --> "policy based QoS" --> "network" --> "extended QoS properties" is probably the easiest way to get this done. That lets you configure rates from 64kB/s (0) to 16MB/s (3).But it's not _really_ a slow speed link, it just allows fewer packets to come in... – Damon Nov 14 '13 at 16:20
  • @Damon Thanks for the insight. How do I go to "policy based QoS"? Is it somewhere in the control panel? I want to simulate longer intervals of time for the same data transfer, so fewer packets would be fine. – sashoalm Nov 14 '13 at 16:30
  • Typing "group" in the run box should bring up the group policy editor, on the left there's a pane where you can select computer config --> windows settings. Under that, you find QoS too. At least it looks like that under my Win7 "professional", might be different if you have "home" or something else. Exact names might vary a bit, too. MS translates everything, and my version is German. So it's always a bit of guesswork what things are called in English (there's little or no hint as to what's the correct terms). – Damon Nov 14 '13 at 16:43
  • @Damon Thanks, I found it and I put a policy of 5KB/s, but it still doesn't seem to be honored. I'm testing it on a VirtualBox machine, with the VirtualBox's virtual network driver. Could this be why it's not working? Also, do those policies affect localhost connections? – sashoalm Nov 15 '13 at 07:06
  • I'd assume that it might treat localhost specially, since no packets actually go in or out, but I wouldn't know - sorry. – Damon Nov 15 '13 at 09:07

3 Answers3

2

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).

Ohad
  • 2,752
  • 17
  • 15
  • Thanks, I didn't know VMware could do that. Do you know if VirtualBox also supports it? – sashoalm Nov 15 '13 at 13:52
  • 2
    VirtualBox does seem to support some of these features. Check out https://www.virtualbox.org/manual/ch06.html#network_bandwidth_limit – Ohad Nov 15 '13 at 15:13
2

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

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

Goran Sliskovic
  • 21
  • 2
1

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.

Len Holgate
  • 21,282
  • 4
  • 45
  • 92
  • 1
    While I appreciate unit tests, I want to do realworld-testing, as well. For example, I discovered that the library I use will not notice that the connection has been dropped if I unplug the Ethernet cable. I release memory and resources when notified of the socket's disconnect. Testing my own code would not have warned me of bugs in the libraries I use. – sashoalm Nov 15 '13 at 14:17
  • Actually unplugging the cable shouldn't cause a TCP connection to drop unless you try and send and the cable remains unplugged for the duration of the TCP retries. That's no surprise, is by design and is 'a feature' of TCP. – Len Holgate Nov 15 '13 at 15:08
  • 1
    @LenHolgate Regardless of whether you use unit tests, at some point you need to do verification against the real world behavior to validate your code represents these behaviors accurately. If you implement your code and/or unit tests exclusively based on your assumptions about behavior, you are only testing that you assumptions/knowledge are accurate. If you *think* you are handling an edge case properly, you need to verify your assumptions with an integration test(i.e. real world). Once you've performed that test you can proceed to write/adjust your unit tests and rely on them going forward. – AaronLS Jan 02 '15 at 23:49
  • AaronLS, yes, of course integration testing on real hardware is required. – Len Holgate Jan 04 '15 at 14:43