views:

130

answers:

6

While developing sever applications, it's many times important to know how stuff works when connections slowdown, suddenly die, or have a very low throughput, however since it would cost a fortune to develop a test network that could emulate all the above "features", we need to emulate them through software.

One way to do this would be to alter the client and server applications, but that's not very cost effective either. And the other method would be through intercepting and altering behavior at the OS level, which seems more promising, and the type of tools I'm looking for right now.

My case in particular is with Solaris servers, but generic Unix/BSD tools are more than welcome. Also feel free to post Window's tools as it will probably help others that come along but aren't using Unix.

Thanks!

A: 

My favourite technique is to yank the network cable out.

anon
Yes that technique is actually quite cheap, but it won't emulate slow connections :)
Robert Gould
They don't get much slower than having the cable yanked out :-)
paxdiablo
+2  A: 

IPTABLES will let you strangle bandwidth and such froth, it is maybe not the most intuitive but can be done. (We used a separate box as the 'Strangler' running FreeBSD but I think the IPtables comes on most *nix strains)

For most network impairment stuff I have done I have used a tool called NetDisturb this is windows based however.

Dean
+1  A: 

I wrote a utility that does this. It's written in Java, so you'll need java installed. It performs well and should do what you need. It's called DonsProxy. Just follow the link, and I hope you like it.

Don Branson
A: 

We developed a tool on one of our projects many years ago which was basically a program started by the inetd daemon on a UNIX box. It basically acted as a conduit between a client and server.

For example, if we started it on www.test.box with:

conduit 1465 www.target.box 80

we could then connect clients to it at www.test.box:1465 and it would open a conduit to www.target.box:80 (inetd actually did most of the grunt work of connecting, although we did also have a version which could act as its own long-running server).

The default behavior was to pass everything through in both directions at full speed but it was configurable (at runtime, with commands passed to it via shared memory, but other methods are possible) to:

  • slow down transmissions.
  • corrupt transmissions.
  • lose data.
  • send spurious data. and quite a few others.

It served us well and helped out a great deal with network exception testing.

paxdiablo
+1  A: 

On the client side, trickle is a very easy way to simulate a slow network (it doesn't do any packet dropping, because it's originally meant as a bandwidth shaper, not a testing tool)

Joachim Sauer
A: 

Try Netem for Linux (http://www.linuxfoundation.org/en/Net%3ANetem), or dummynet for BSD.

Nathan