Assertion error on mininet-test experiment

2019-08-28 01:09发布

问题:

My friend and I tried to reproduce this mininet-test experiment: https://github.com/mininet/mininet-tests/tree/master/dctcp

We self created a VM and installed Mininet 2.2 on ubuntu with kernel version 3.18.9, which included dctcp and tcp_probe function.

Since author suggest kernel version 3.0.1 didn't support those function we needed in Mininetnet. We simply changed the some function name in dctcp.py, such as: add_host changed to addHost, add_switch changed to addSwitch ,add_link changed to addLink.

And we also imported some python function we need, such as : python-matplotlib, python-termcolor and bwm-ng.

But we still encounter the following problems when we plotting the graph - cwnd.png.

Are we missing some important lib or any code need to change?

    .Traceback (most recent call last):
      File "dctcp.py", line 250, in <module>
        main()
      File "dctcp.py", line 244, in main
        net.stop()
      File "build/bdist.linux-x86_64/egg/mininet/net.py", line 514, in stop
      File "build/bdist.linux-x86_64/egg/mininet/link.py", line 479, in stop
      File "build/bdist.linux-x86_64/egg/mininet/link.py", line 472, in delete
      File "build/bdist.linux-x86_64/egg/mininet/link.py", line 199, in delete
      File "build/bdist.linux-x86_64/egg/mininet/link.py", line 64, in cmd
      File "build/bdist.linux-x86_64/egg/mininet/node.py", line 350, in cmd
      File "build/bdist.linux-x86_64/egg/mininet/node.py", line 269, in sendCmd
    AssertionError
    s1
    s1-eth1
    s1-eth2
    s1-eth3
    total
    ['tcp-n3-bw100/qlen_s1-eth1.txt']

回答1:

I ran into this as well, and found that if you look at: https://github.com/bigswitch/mininet/blob/master/mininet/node.py and in the monitor() function section you will see that this function sets the waiting flag = False.

So the code can be

h1.sendCmd(startbackground_service)
h2.cmd(something_else)
h3.cmd(use_h1_service)
.....
#at some point end h1's background service, naturally or unnaturally
h1.monitor() # will check the service, and set waiting=False


回答2:

The code seems to set a flag waiting at the end of a sendCmd() call, the flag is check to be False on every run of the method. It seem to be reset when the result of the command is received.

As the result you can't send a second command until the response of the first is received. This might just be a race condition but IMHO the library should handle that case in a more clever and transparent way.