Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Fix for Windows build (cli_test and socket.h) #1305
referenced this pull request
Sep 3, 2018
We have the Application class, and in the real world we pass in boost::program_options for what port to bind to for P2P communication as well as API connections. If we do not specify these parameters, I believe they do not bind to ports. Are you saying we should pass parameters to the Application class to tell it to select its own unused port, and then we can later query for which ports it binds to? I know that you know that such a change is out of the scope of this fix, so I must be misunderstanding your question.
Perhaps it's out of scope, but I still think it's better to have it.
Let me see if I am clear:
For P2P, if we don't specify a port, it binds to a random available port. Querying afterward makes sense, and is already implemented.
For the rpc endpoint, the user has the option to pass in a port number. In the "real world" they will either (1) not want one, or (2) have one in mind so that they can connect their clients to it. In the "testing world" we just want a random port, and don't need to share that port number with anyone outside the test.
I believe what you are proposing is for tests to set the parameter "rpc-endpoint" to something like "127.0.0.1:0" and let the websocket server select an available port. We can then provide an
Thanks for the explanation. I guess I was wrong (was thinking about p2p port while the function is about rpc port). To be clear, in the real world, I don't want the feature to bind to a random rpc port, so it doesn't make sense to have it just for test (even if we have it, we still need to test specified port).