I've tested it with many hundred in the past using a modified cbench. It's
easier now, since POX contains its own OpenFlow switch. I just ran:
#!/bin/bash
for I in $(seq 1 300); do
./pox.py datapaths:softwareswitch &
done
The controller does stop somewhere around 250 connections, which would be
highly suspicious due to its proximity to 256, but in my case, the problem was
clearly visible in the log:
ERROR:openflow.of_01:Exception reading connection <socket._socketobject object
at 0x10e009d00>
Traceback (most recent call last):
File "/Users/murphy/proj/pox_dart/pox/openflow/of_01.py", line 905, in run
new_sock = listener.accept()[0]
File
"/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/socket.py",
line 202, in accept
error: [Errno 24] Too many open files
ERROR:openflow.of_01:Exception on OpenFlow listener. Aborting.
POX has run out of file descriptors and the resulting error has caused the
OpenFlow loop to abort. I set it larger using ulimit (500 was the largest I
could get without changing the system config), and could now get almost 500
connected.
Did you not get this log message? As the FAQ says, posting the log can be very
useful. You also don't really describe what you mean by "freeze", though it
may be hard to tell. For example, if the OpenFlow loop aborted, POX would
appear to freeze as far as OpenFlow was concerned, though timers and other
components would continue to run.
It's not clear why setting the connection rate to two per second would help if
the problem was running out of file descriptors unless this led to some of the
switches disconnecting (or being disconnected due to idle)... which might be
obvious from reading the log.
At any rate, aborting the OpenFlow loop when out of file descriptors is
probably just not the right thing to do. I've pushed a fix to dart.
-- Murphy
On Nov 30, 2013, at 12:31 PM, Nan Zhu <zhunanmcg...@gmail.com> wrote:
> Hi,
>
> Do anyone has some experimental result about the pox capacity in terms of
> concurrent connection number?
>
> I wrote some software-defined openflow switch (partially implement the
> openflow protocol, except the packet counters and queues), each switch is a
> in-memory object which can connects to the pox and send openflow messages,
>
>
> it works well when the number of "openflow switches" is small. however, when
> I create as many as 320 switches, the pox controller freeze after it
> processed connectUp for nearly 250 switches
>
> I controlled the connection rate as 2 connectionup per second, it backs to
> the normal
>
> anyone has the similar experience?
>
> Best,
>
> Nan
