views:

1146

answers:

13

I've had a bug in our software that occurs when I receive a connection timeout. These errors are very rare (usually when my connection gets dropped by our internal network). How can I generate this kind of effect artificially so I can test our software?

If it matters the app is written in C++/MFC using CAsyncSocket classes.

Edit:

I've tried using a non-existant host, and I get the socket error:

WSAEINVAL (10022) Invalid argument

My next attempt was to use Alexander's suggestion of connecting to a different port, e.g. 81 (on my own server though). That worked great. Exactly the same as a dropped connection (60 second wait, then error). Thank you!

A: 

Plug in your network cable into a switch which has no other connection/cables. That should work imho.

GHad
A: 

Or just try to connect to a non existent host

Vinko Vrsalovic
A: 

I like to use CurrPorts to manipulate network connections when debugging. Sometimes, just unplugging the network cable will do just as fine (as posted by others).

Mathias
+4  A: 

Connect to an existing host but to a port that is blocked by the firewall that simply drops TCP SYN packets. For example, www.google.com:81.

Alexander
A: 

There are a couple of tactics I've used in the past to simulate networking issues;

  1. Pull out the network cable
  2. Switch off the switch (ideally with the switch that the computer is plugged into still being powered so the machine maintains it's "network connection") between your machine and the "target" machine
  3. Run firewall software on the target machine that silently drops received data

One of these ideas might give you some means of artifically generating the scenario you need

Rob
A: 

Depending on what firewall software you have installed/available, you should be able to block the outgoing port and depending on how your firewall is setup it should just drop the connection request packet. No connection request, no connection, timeout ensues. This would probably work better if it was implemented at a router level (they tend to drop packets instead of sending resets, or whatever the equivalent is for the situation) but there's bound to be a software package that'd do the trick too.

Matthew Scharley
A: 

I had issues along the same lines you do. In order to test the software behavior, I just unplugged the network cable at the appropriate time. I had to set a break-point right before I wanted to unplug the cable.

If I were doing it again, I'd put a switch (a normally closed momentary push button one) in a network cable.

If the physical disconnect causes a different behavior, you could connect your computer to a cheap hub and put the switch I mentioned above between your hub and the main network.

-- EDIT -- In many cases you'll need the network connection working until you get to a certain point in your program, THEN you'll want to disconnect using one of the many suggestions offered.

Brad Bruce
A: 

You can try to connect to one of well-known Web sites on a port that may not be available from outside - 200 for example. Most of firewalls work in DROP mode and it will simulate a timeout for you.

Dmitry Khalatov
A: 

The easiest thing would be to drop your connection using CurrPorts.

However, in order to unit test your exception handling code, perhaps you should consider abstracting your network connection code, and write a stub, mock or decorator which throws exceptions on demand. You will then be able to test the application error-handling logic without having to actually use the network.

Matt Howells
A: 

You might install Microsoft Loopback driver that will create a separate interface for you. Then you can connect on it to some service of yours (your own host). Then in Network Connections you can disable/enable such interface...

Marcin Gil
A: 

Despite it isn't completely clear which one the OP wants to test: there's a difference between attempting a connection to a non-existent host/port and a timeout of an already established connection. I would go with Rob and wait until the connection is working and then pull the cable. Or - for convenience - have a virtual machine working as the test server (with bridged networking) and just deactivating the virtual network interface once the connection is established.

+1  A: 

Connect to a non-routable IP address, such as 10.255.255.1.

emu
This worked for me.
Jesse Wilson
A: 

How about a software solution:

Install SSH server on the application server. Then, use socket tunnel to create a link between your local port and the remote port on the application server. You can use ssh client tools to do so. Have your client application connect to your mapped local port instead. Then, you can break the socket tunnel at will to simulate the connection timeout.

stoneboy