<div dir="ltr">Yeah, I've got a few ideas on how I could do it. Just gonna take a lot of playing and testing. Thanks again for bringing up tuntap though (and for writing a library to make using them easier ), it's opened up some new possibilities for when I've got time (one more feature against the current code base and it does everything I want it to for my current project, but rewriting to leverage tuns or taps would let me subsume all the related functionalities I've seen/thought of in some manner or other, in a portable manner, which is...really, really cool). </div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 7, 2015 at 12:42 PM, Michael Santos <span dir="ltr"><<a href="mailto:michael.santos@gmail.com" target="_blank">michael.santos@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wed, Jan 07, 2015 at 11:00:42AM -0500, Christopher Phillips wrote:<br>
>   Thanks for that. Yeah, I had a look at your tuntap library, and it looks<br>
> like both a portable way to reimplement the existing functionality, but<br>
> also some ways to add some features more easily that I intended anyway, and<br>
> some I had mentally dismissed as too unpleasant. I just need to find time<br>
> to play with it and confirm/evolve my mental model. I'm thinking I'm going<br>
> to try dropping one more feature on the existing code base, then start<br>
> experimenting on a branch.<br>
<br>
</span>Yeah, just a suggestion, not sure it will work out for you. By the way,<br>
very cool project!<br>
<span class=""><br>
> There's some complexity in managing multiple<br>
> destinations from one source, as well as the actual implementation of<br>
> drop/delay (I need to make it so queued packets don't chain their delay.<br>
> I.e., if I changed the code in that example to have a solid 1 second delay,<br>
> for every frame coming in, and I got 5 frames in rapid succession, I'd have<br>
> one received at the destination after one second, the next after two, the<br>
> next after three, etc. I need to track when I received them and apply rules<br>
> appropriately, across multiple nodes)<br>
<br>
</span>One way would be to have a number of buckets for holding frames. Each<br>
bucket is an erlang process. Frames are distributed across the processes<br>
and if the mailbox queue exceeds some size, new frames are discarded.<br>
<div class="HOEnZb"><div class="h5"><br>
> On Wed, Jan 7, 2015 at 10:20 AM, Michael Santos <<a href="mailto:michael.santos@gmail.com">michael.santos@gmail.com</a>><br>
> wrote:<br>
><br>
> > On Mon, Jan 05, 2015 at 08:55:06PM -0500, Christopher Phillips wrote:<br>
> > >   Hmm, I've had so little experience with tuntap interfaces I didn't<br>
> > think<br>
> > > of them. That sounds like the way to go to get things working on OSX,<br>
> > > though at a much larger amount of effort (both the learning curve on my<br>
> > > part, and re-implementing the degradation behaviors I get for free from<br>
> > the<br>
> > > kernel). Thanks for suggesting it; once I get things to where it's usable<br>
> > > on Linux in all the ways I want, some research and a rewrite may be in<br>
> > > order to get it fully portable.<br>
> ><br>
> > Sure, that is definitely reasonable.<br>
> ><br>
> > Working with tuntap devices isn't too difficult. For comparison, here is<br>
> > a very simple example that forwards ethernet frames over erlang<br>
> > distribution and randomly drops or delays a percentage of the frames:<br>
> ><br>
> > <a href="https://gist.github.com/msantos/f2823fcba40975003dc3" target="_blank">https://gist.github.com/msantos/f2823fcba40975003dc3</a><br>
> ><br>
> > Set up 2 distributed nodes:<br>
> ><br>
> >     erl -name n@peer1.ip -setcookie CHOCOLATEBUTTERSCOTCH<br>
> >     erl -name n@peer2.ip -setcookie CHOCOLATEBUTTERSCOTCH<br>
> ><br>
> > Then create the tunnel:<br>
> ><br>
> >     % Drop 10% of the frames, randomly delay 40% up to 1 second<br>
> >     wastrel:start('n@peer2.ip', "10.1.1.1", "10.1.1.2", 0.1, 0.4).<br>
> ><br>
> > Try to login using ssh (or whatever)!<br>
> ><br>
> >     ssh 10.1.1.2<br>
> ><br>
> > Meh, I've had to use worse ...<br>
> ><br>
> > Notes:<br>
> > * relies on this erlang tuntap driver<br>
> ><br>
> >     <a href="https://github.com/msantos/tunctl" target="_blank">https://github.com/msantos/tunctl</a><br>
> ><br>
> > * beam needs to be running as root or have CAP_NET_ADMIN set:<br>
> ><br>
> >     sudo setcap cap_net_admin=ep /usr/local/lib/erlang/erts-*/bin/beam*<br>
> ><br>
> > > On Mon, Jan 5, 2015 at 8:11 PM, Michael Santos <<a href="mailto:michael.santos@gmail.com">michael.santos@gmail.com</a><br>
> > ><br>
> > > wrote:<br>
> > ><br>
> > > > On Mon, Jan 05, 2015 at 09:16:42AM -0500, Christopher Phillips wrote:<br>
> > > > > For OSX ipfw was deprecated in Lion and removed in Yosemite. I've<br>
> > done a<br>
> > > > > bit of looking at the replacement, pf, and it looks like dropping<br>
> > packets<br>
> > > > > based on percentage is doable, as is bandwidth throttling (something<br>
> > I'd<br>
> > > > > like to add, in general), but I don't see any way to induce a delay,<br>
> > > > beyond<br>
> > > > > an implicit one based on tos prioritization. If someone knows how<br>
> > and can<br>
> > > > > point me in the right direction I'd appreciate it.<br>
> > > ><br>
> > > > The portable way is to use a tuntap device. Then you can arbitrarily<br>
> > > > drop packets, throttle bandwidth, introduce latency, whatever, from<br>
> > your<br>
> > > > code. Sort of like quickcheck for networks :)<br>
> > > ><br>
> > > > > On Mon, Jan 5, 2015 at 6:52 AM, Sergej Jurečko <<br>
> > <a href="mailto:sergej.jurecko@gmail.com">sergej.jurecko@gmail.com</a><br>
> > > > ><br>
> > > > > wrote:<br>
> > > > ><br>
> > > > > > This looks like a great tool and something that could easily be<br>
> > added<br>
> > > > to<br>
> > > > > > unit tests.<br>
> > > > > > Anyone with ipfw skills to add bsd/osx support?<br>
> > > > > ><br>
> > > > > > Sergej<br>
> > > > > > On Jan 5, 2015 1:41 AM, "Christopher Phillips" <<br>
> > <a href="mailto:lostcolony@gmail.com">lostcolony@gmail.com</a>><br>
> > > > > > wrote:<br>
> > > > > ><br>
> > > > > >> <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<br>
> > > > > >> libraries or similar for testing distribution scenarios. I only<br>
> > got<br>
> > > > back a<br>
> > > > > >> few responses (maybe co-op riak_test? Maybe make use of the<br>
> > underlying<br>
> > > > > >> Linux traffic control and network emulation apps?), and my own<br>
> > > > searches,<br>
> > > > > >> while finding a few libraries, didn't find anything I could easily<br>
> > > > co-op<br>
> > > > > >> for my purposes.<br>
> > > > > >><br>
> > > > > >> To that end, I went ahead and spent part of my break on this, and<br>
> > it<br>
> > > > just<br>
> > > > > >> got sufficiently feature complete to throw out there. I haven't<br>
> > had a<br>
> > > > > >> chance to really start using it heavily, and I've only been<br>
> > testing<br>
> > > > it on<br>
> > > > > >> my dev box, but a basic run through of the functionality as I<br>
> > typed<br>
> > > > up the<br>
> > > > > >> readme worked (so any issues being pointed out would be<br>
> > appreciated).<br>
> > > > > >> Essentially, it allows you to create and manipulate local<br>
> > interfaces<br>
> > > > on a<br>
> > > > > >> Linux machine to emulate packet delay and loss (using the<br>
> > underlying<br>
> > > > > >> traffic control and network emulation mechanisms), with a number<br>
> > of<br>
> > > > > >> convenience methods to (hopefully) easily describe fairly<br>
> > intricate<br>
> > > > > >> distribution scenarios.<br>
> > > > > >><br>
> > > > > >> Things like "create these 5 interfaces, (now from my test code,<br>
> > > > launch a<br>
> > > > > >> copy of my app on each one, or even a different app on one of<br>
> > them,<br>
> > > > to see<br>
> > > > > >> what happens when that resource is flaky); now make it so 1 and 2<br>
> > > > can't<br>
> > > > > >> talk to 3 and 4, and vice versa, but everyone can still talk to<br>
> > 5, but<br>
> > > > > >> replies have a 50% chance of being dropped from 5 when responding<br>
> > to<br>
> > > > 1 and<br>
> > > > > >> 2, and there's a 300ms delay between 3 and 4; (now, let's run<br>
> > more of<br>
> > > > our<br>
> > > > > >> test code to assert that trying to write to any node still<br>
> > succeeds);<br>
> > > > okay,<br>
> > > > > >> now let's restore the network back to normal (and have our test<br>
> > code<br>
> > > > make<br>
> > > > > >> sure the write was retained)", or whatever, can be set up in a<br>
> > > > > >> straightforward, automated manner as part of a common test run,<br>
> > and<br>
> > > > not be<br>
> > > > > >> reliant on certain VMs being up, nor the tests being run on a<br>
> > specific<br>
> > > > > >> network. The tradeoff, obviously, being that you can't really load<br>
> > > > test<br>
> > > > > >> things with it. Still, it fits my basic needs, and I figured it<br>
> > might<br>
> > > > be of<br>
> > > > > >> use to others.<br>
> > > > > >><br>
> > > > > >> I'll be adding some simple examples when I next get free time (I<br>
> > ran<br>
> > > > out<br>
> > > > > >> of it from the holiday break without getting to them; dunno when I<br>
> > > > will),<br>
> > > > > >> and will try and get to any bugs or simple suggestions in a timely<br>
> > > > manner,<br>
> > > > > >> but hopefully it's fairly straightforward and useful as is.<br>
> > > > > >><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>
> > > > > >><br>
> > > ><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>
> > > ><br>
> ><br>
</div></div></blockquote></div><br></div>