Whisper cli

[niklasad1]

Hey,

This is an attempt to close #6138

EDIT:
I removed the tests for because it more or less requires duplication of the existing tests in rpc and whisper because these are private I can't just use them directly.

It's alot of work re-implement (copy-paste) them so I don't think it is worth the effort. But maybe a couple of CLI arguments tests and some rough test that jsonrpc at least works!

Thoughts?

[parity-cla-bot]

It looks like @niklasad1 signed our Contributor License Agreement. 👍

Many thanks,

Parity Technologies CLA Bot

[5chdn]

Nice. /cc @gballet FYI

Needs docs once merged.

[rphmeier]

maybe clarify that this is the RPC port, not the devp2p port

[rphmeier]

except for the small grumble, LGTM.
w.r.t. tests I think tests that make sure the filter manager and other RPCs are working as expected would be nice (this might require a more abstraction around the pub/sub and network but maybe not much), but beyond that I don't see unit tests that make sure the RPCs actually invoke those methods as expected will be useful since the JSONRPC crate is well tested already. Those tests can be added in a follow-up PR.

[niklasad1]

@rphmeier

I noticed a very interesting bug BTW if you run:

$ whisper-cli --port=24``` (i.e, a privileged port requires root access)

The error is not always propagated I guess it has wait for all other resources to released which may not happen that could be annoying for the user who may think that cli is running.

So I lean towards using expect instead of proper error handling but then the panic-hook will report this as a bug. Should I use expect and drop the panic-hook then?

[rphmeier]

I think we should use proper error handling; this failure is likely due to other bugs in the whisper, network, or RPC implementation and we should fix those rather than working around them.

[niklasad1]

@rphmeier

I think it is good to go now, but I had to introduce an additional variable to cancel/join the Decryption Worker Thread because the mspc sends Fn() closure which I can't determine whether it is an actual message or to cancel the thread.

Alternately we could just skip joining threads and terminate!

[rphmeier]

Alternately we could just skip joining threads and terminate!

Yep, also an option. Either is an improvement over deadlock :)