BUS example does not work (Windows)

[dannypike]

I am having trouble running the BUS example code using a Windows build of NNG. Only a few of the nodes seem to send messages.

I looked more closely at the code and noticed that the dialler loop seems to have the wrong starting value.

However, even after changing this: for (int x = 3; x < argc; x++) {

to this: for (int x = 2; x < argc; x++) {

it still doesn't behave as I expect.

On my machine, the nodes send themselves multiple copies of their own messages and some other messages don't get sent to all nodes. I edited the example code to give more debug and produced a swim-lanes plot of what appears to be happening in which order.

I attach an Excel spreadsheet showing the swimlanes output (reformatted and cleaned up a bit) and I also attach a copy of the modified example that produced it.

I tried using the NNG build that is available on vcpkg (dated 27th February) and also the latest image (7b6e73f) from Github as of the time I am writing this. Both versions behave in the same, unexpected way.

I used CMake 3.15.0-rc3 and Ninja 1.7.2 to build the version that is shown in the attached swimlanes output. The build does produce one warning, but I don't think it's relevant to this issue:

[294/306] Building CXX object tests\CMakeFiles\cplusplus_pair.dir\cplusplus_pair.cc.obj D:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.21.27702\include\ostream(708): warning C4530: C++ exception handler used, but unwind semantics are not enabled. Specify /EHsc ..\tests\cplusplus_pair.cc(71): note: see reference to function template instantiation 'std::basic_ostream<char,std::char_traits<char>> &std::operator <<<std::char_traits<char>>(std::basic_ostream<char,std::char_traits<char>> &,const char *)' being compiled

All of the tests passed, thought they seemed to be happy to complete even before I allowed them to connect out through the Windows Defender firewall, which may or may not be important.

nng_bus.zip

[gdamore]

The starting value is correct. argv values are as follows:

0 - usually the name of the program 1 - a "name" for the instance - this is used in printing so you can tell which message is from which 2 - the URL to bind to -- i.e. our own name. 3 (and beyond) - the URL(s) of any peers to which we should connect

My guess is that you've misunderstood the example.

Note also that you need to start all those node instances in rapid succession -- as part of a shell script. If you're trying to run them by hand, then you'll probably get timeouts or messages not delivered.

The warning about the example is indeed unrelated -- Studio needs a special command line argument used when building C++ programs with exceptions, and C++ streams use those.

[gdamore]

Please try the program as indicated (you should make a batch file for the bus intances, or you can do this under WSL) and come back with the specific output you received.

[dannypike]

Thank you for your response.

I am using a batch file to launch all the nodes in my tests. My original post was derived from empirical experimenting with the connections to produce the "best" results, as defined by having fewest messages being lost. I achieved this by making the nodes connect to themselves explicitly, which seemed to be reasonable to me at the time, because the if (argc >= 3) { statement suggests that the starting index for argv[] in the for() that follows should actually be 2, not 3.

When I used the algorithm as shown in the README (I had to modify the code slightly so that it manages to compile on Windows and sleeps for a full second), the results are worse than with the greatly-modified version in my original post. A screenshot of a run using this original code can be found here, alongside the batch script that I used to run it.

Perhaps you could give me a set of sources that will compile on a Windows machine with a Visual Studio 2019 toolset, and I can try it directly and without having to modify anything?

[gdamore]

You generally don't want nodes to connect to themselves. That's a misapplication of the pattern.

Having said that, I do see a bug in the application code. Stay tuned.

[gdamore]

So the test was wrong, but the for loop was correct.

[gdamore]

In fact the test is entirely superfluous.

[dannypike]

I agree that it is unnecessary; I was changing things to see if I could get it to match the output that was in the README, so I assumed it might have been a typo. As a rule, I tend to follow the "design pattern" of hitting buttons at random until it delivers a drinkable cup of tea.

[gdamore]

This issue is aged. Closing as stale.

[dannypike]

OK, that' s no problem for me. I gave up waiting ages ago, and swapped to another technology.