Content-Transfer-Encoding: binary Message-ID: X-RT-Original-Encoding: utf-8 In-Reply-To: X-RT-Interface: Web Content-Disposition: inline References: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Mailer: MIME-tools 5.508 (Entity 5.508) RT-Send-CC: Content-Length: 2002 >> More seriously I really prefer the "more robust" option as I >> run tests on an other purpose machine. BTW a feature which >> is very useful in some cases should come for free (i.e. just >> check it works) with random is to be able to run simultaneously; >> the same test on different builds. > > If you provide the script that will print the usable port number to > stdout, we would integrate it. I've already done this. "make" is used to run the tests in parallel: instead of putting the dependencies in the main Makefile (which is where the difficulties of assigning unique ports arises), I've got it to dynamically create a temporary makefile where each test is assigned a unique port, and to recursively run "make" on that. >> => 32k available but 1/2 collision probability after ~180 ports. > We have 103 system tests now and only the most time critical are being ported. Although the issue with the clash on the query and control port has been resolved, there is another source of clash. Evan raised the point that after Kaminski, BIND uses a random port for each upstream query. If we have multiple instances of BIND running on the same IP address, it is possible that more than one instance will choose the same port at approximately the same time. There is no guarantee which instance will receive which response. The probability of this happening during an individual test is small, but we run tests continuously on multiple machines. Sooner or later there will be a clash and we will have an apparent random failure. I think we could get round this by adding a statement of the form "use-v4-udp-ports " to the configuration files, with a unique range of ports being chosen for each test. Given the number of tests, I'd suggest giving each test a pool of 200 ports in the range 20,000 to 60,000. This will allow for up to 200 tests before we need to start thinking about port ranges. I don't think this will have an impact on the tests but I'd appreciate input.