Add IPC (pipetx) events to report listening ports

[matheusd]

Something similar to decred/dcrwallet#986

The goal would be to allow running dcrd with --listening :0 --rpclisten :0, have dcrd bind to a random unused port and have it report back to a controlling process which ports those services were bound to.

This would allow more reliable automation of dcrd in scenarios where it is executed multiple times in the same environment (for example, when running multiple instances during an integration test) or when it is ran automatically in a user machine that may have other services bound to the same port (for example, when running from decrediton).

This is one alternative for implementing decred/dcrtest#4

[davecgh]

This seems like a reasonable idea and would definitely help with automation as mentioned.

[jrick]

possibly a better/another idea to explore would be for the parent process to allocate a pipe/socket and pass the file descriptor (through a command line arg?). We could drop tcp, tls... and the server would not be able to be used by any other process.

The way I did it in wallet year ago works, but it just feels super clunky to me now.

[jrick]

Hmm, I think i now recall why we didn't do that before, anonymous pipes on windows are only unidirectional.

[davecgh]

I'm not sure how much support Go has for it, but it could always just use a duplex named pipe on Windows instead. An anonymous pipe on Windows is really just a named pipe with a unique name under the hood and the open mode set to either inbound or outbound instead of duplex anyway.

[matheusd]

possibly a better/another idea to explore would be for the parent process to allocate a pipe/socket and pass the file descriptor (through a command line arg?). We could drop tcp, tls... and the server would not be able to be used by any other process.

Using a pipe would indeed be better security wise (relevant PR in dcrwallet is decred/dcrwallet#1288 - though note that was for switching to named pipes for IPC, not for actual networking).

For automation allowing pipes wouldn´t be sufficient: we might want dcrd bound to a random port but accessible to any process, so a pipe solution wouldn´t work in this scenario (you´d still need some way to report to the parent process the port dcrd was eventually bound to).