On Oct 30, 2013, at 4:13 PM, Victor Torres <[email protected]> wrote: > Murphy, > > Thank you for your fast reply! I understand the issues and I'm looking for > alternatives right now. > > One more question that you might help me: can you guess what order > (thousands? Hundreds of thousands?) of request rate would be necessary for me > to see any time increase in some other (legit) stats_request from some other > controller?
No clue; sorry. I'd imagine it depends heavily on what switch you're using. -- Murphy > On 30 October 2013 20:49, Murphy McCauley <[email protected]> wrote: > First, in Python, multiple threads don't actually execute concurrently due to > the Global Interpreter Lock, so you may not be gaining much through the > multithreaded approach. > > Second, connection objects in POX should always only be used from the > cooperative thread. So instead of writing actual threads, you could write > recoco Tasks which do more or less the same thing (except they "yield > Sleep(time_step)" rather than "time.sleep(time_step)"). There's been some > discussion on writing tasks over the last couple days (in the "Timer function > acts strange when called sequentially" thread), and there's a bit of an > example in lib/recoco/examples.py too. > > If you're trying to stress test, I'd suggest you run the dart branch of POX > with the --unthreaded-sh option which is faster for this sort of thing. It's > possible POX/Python will be the bottleneck here anyway. It's not designed > for creating DoS attacks. NOX would be a better choice if you're really > trying to stress your switches and you have fast links. > > -- Murphy > > On Oct 30, 2013, at 3:29 PM, Victor Torres <[email protected]> wrote: > > > Hello, > > > > I'm currently trying to make a controller aplication in POX that, after a > > switch connects, floods the switch with stats_requests. My idea is just to > > make it so it looks like a "Denial of Service". > > > > I'm currently trying to use python's thread library, like the below: > > > > " > > for i in range(number_threads): > > thread.start_new_thread( stress_function, (connection, i+1, > > request_rate/number_threads) ) > > " > > > > And every thread is trying to do something like the following, and this is > > where I actually try to flood with stats_requests: > > > > " > > while(elapsed_time < test_duration): > > time.sleep(time_step) > > > > connection.send(of.ofp_stats_request(body=of.ofp_flow_stats_request())) > > " > > > > The problem is that I get the following error when running with multiple > > threads: > > > > " > > Unhandled exception in thread started by <function stress_function at > > 0x20ccc80> > > Traceback (most recent call last): > > File "/root/pox/ext/dos_test.py", line 45, in stress_function > > connection.send(of.ofp_stats_request(body=of.ofp_flow_stats_request())) > > File "/root/pox/pox/openflow/of_01.py", line 687, in send > > data = data.pack() > > File "/root/pox/pox/openflow/libopenflow_01.py", line 2470, in pack > > packed += ofp_header.pack(self) > > File "/root/pox/pox/openflow/libopenflow_01.py", line 554, in pack > > len(self), self.xid) > > File "/root/pox/pox/openflow/libopenflow_01.py", line 537, in xid > > self._xid = generate_xid() > > ValueError: generator already executing > > " > > > > It seems that the concurrent stats_request callings is generating this > > problem. Can anyone give me any advice on how to properly do this in an > > effective way? I doesn't need to use POX itself, I just need to have > > control over the request rate. > > > > > > Thanks in advance! > > > > Victor T. > >
