<p dir="ltr">This looks like a great tool and something that could easily be added to unit tests. <br>
Anyone with ipfw skills to add bsd/osx support? <br></p>
<p dir="ltr">Sergej</p>
<div class="gmail_quote">On Jan 5, 2015 1:41 AM, "Christopher Phillips" <<a href="mailto:lostcolony@gmail.com">lostcolony@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><a href="https://github.com/lostcolony/damocles" target="_blank">https://github.com/lostcolony/damocles</a><br><br>I asked a while back on this mailing list if anyone had any useful libraries or similar for testing distribution scenarios. I only got back a few responses (maybe co-op riak_test? Maybe make use of the underlying Linux traffic control and network emulation apps?), and my own searches, while finding a few libraries, didn't find anything I could easily co-op for my purposes.<br><br>To that end, I went ahead and spent part of my break on this, and it just got sufficiently feature complete to throw out there. I haven't had a chance to really start using it heavily, and I've only been testing it on my dev box, but a basic run through of the functionality as I typed up the readme worked (so any issues being pointed out would be appreciated). Essentially, it allows you to create and manipulate local interfaces on a Linux machine to emulate packet delay and loss (using the underlying traffic control and network emulation mechanisms), with a number of convenience methods to (hopefully) easily describe fairly intricate distribution scenarios. <br><br>Things like "create these 5 interfaces, (now from my test code, launch a copy of my app on each one, or even a different app on one of them, to see what happens when that resource is flaky); now make it so 1 and 2 can't talk to 3 and 4, and vice versa, but everyone can still talk to 5, but replies have a 50% chance of being dropped from 5 when responding to 1 and 2, and there's a 300ms delay between 3 and 4; (now, let's run more of our test code to assert that trying to write to any node still succeeds); okay, now let's restore the network back to normal (and have our test code make sure the write was retained)", or whatever, can be set up in a straightforward, automated manner as part of a common test run, and not be reliant on certain VMs being up, nor the tests being run on a specific network. The tradeoff, obviously, being that you can't really load test things with it. Still, it fits my basic needs, and I figured it might be of use to others.<br><br>I'll be adding some simple examples when I next get free time (I ran out of it from the holiday break without getting to them; dunno when I will), and will try and get to any bugs or simple suggestions in a timely manner, but hopefully it's fairly straightforward and useful as is. </div>
<br>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br></blockquote></div>