Merge pull request #3 from MASQ-Project/GH-386

Gh-386: formerly panics at double-used "shutdown" ; ended with broad redesign of some structures in masq

.github/workflows/ci-matrix.yml

@@ -24,9 +24,18 @@ jobs:
           key: ${{ runner.os }}-0001
       - name: Build ${{ matrix.os }}
         run: |
-          rustup show
-          rustup update stable
-          rustup show
+          rustup check
+          case "$OSTYPE" in
+            msys)
+              echo "Windows doesn't like it when rustup updates itself"
+              rustup update --no-self-update stable
+              ;;
+            *)
+              echo "Linux and macOS don't need manual suppression of rustup self update"
+              rustup update stable
+              ;;
+          esac
+          rustup check
           rustup component add rustfmt
           rustup component add clippy
           ./ci/all.sh

.gitignore

@@ -74,6 +74,10 @@ Temporary Items
 # CMake
 cmake-build-debug/
 
+# Azure
+.idea/azure*
+.idea/azure/
+
 # Mongo Explorer plugin:
 **/.idea/**/mongoSettings.xml
 

USER-INTERFACE-INTERFACE.md

@@ -104,14 +104,34 @@ going on at once, this might happen:
 1. ← Response for conversation 2
 
 If each conversation has its own ID, it'll be a lot easier to tell what's going on when a message arrives
-than it will be if every message is part of conversation 555.
+than it will be if every message is part of conversation 555. Even more importantly, if two or more of
+those requests have the same opcode, figuring out which response goes with which request can be completely
+impossible if all the requests are in the same conversation.
+
+The reason the concept of conversations exists is the fact that many of the messages in the `MASQNode-UIv2`
+protocol are requests in a particular context that specifically demand responses in the same context. The
+conversation, whether you choose to use a new conversation for every exchange, or the same conversation for
+all of them, or some compromise scheme, serves to fix the context and bind together a request with its
+response or responses.
+
+In `MASQNode-UIv2`, all responses to a particular conversational request will always have the same opcode
+as that request. In situations where responses to a particular request can have different meanings (for
+example, in the case where the request is a subscription to a class of messages), all the responses will
+have the same opcode, but another common field in the responses may be chosen to act as a secondary opcode
+to distinguish them from one another.
 
 Some messages are always isolated, and never part of any conversation, like the Broadcast in step 5 above. 
 These messages will be identifiable by their `opcode`, and their `contextId` should be ignored. (In the 
-real world, it's always zero, but depending on that might be dangerous.)
+real world, it's always zero, but depending on that might be dangerous.) These isolated messages cannot
+reasonably be called requests, since A) they neither expect nor provoke any response, except in certain error
+situations, and B) provide no meaningful `contextId` to identify a conversation that would bind a response
+to them.
 
 Neither the Daemon nor the Node will ever start a conversation, although they will send isolated, non-conversational
-messages.
+messages. In the error situations mentioned above, the error notifications will arrive as isolated messages
+and should either be ignored or presented to the user in a general-error format. The error report will
+almost certainly have a different opcode from the message that provoked the error, and there will probably
+be no tractable way to semantically connect the two.
 
 The `payload` is the body of the message, with its structure being signaled by the contents of the `opcode` field.
 See the Message Reference section below for specifics about the `payload` field for each type of message.
@@ -458,6 +478,27 @@ Requests the Node descriptor from a Node.
 ##### Description:
 Contains a Node's Node descriptor.
 
+#### `undelivered`
+##### Direction: Response
+##### Correspondent: Daemon
+##### Layout:
+```
+"payload": {
+    "opcode": <string>,
+    }
+}
+```
+##### Description:
+When the Daemon receives a fire-and-forget message (which is a case not being implemented at the time of writing this;
+all such messages go only in the opposite direction now), the normal way to proceed would be to look whether that type 
+of message is known to the Daemon. If not, then it tries to send a redirect message. However, if it turns out, at the 
+same moment, that the Node is not running there is no sense in it, and the action should not be completed. On the other
+hand, we want the UI, or the user respectively to know that this has happened otherwise they might think that a certain
+operation was executed though wasn't. This message comes back to the sender (UI) saying that a message with a certain
+opcode could not be delivered because Node is not running.
+
+`opcode` means the opcode taken from the original message received by the Daemon.
+
 #### `financials`
 ##### Direction: Request
 ##### Correspondent: Node

dns_utility/src/dynamic_store_dns_modifier.rs

@@ -351,10 +351,8 @@ impl StoreWrapper for StoreWrapperReal {
         let pairs: Vec<(CFString, CFArray)> = dictionary
             .into_iter()
             .flat_map(|(key, cfpl_value)| {
-                match CFPropertyList::downcast_into::<CFArray>(cfpl_value) {
-                    Some(v) => Some((CFString::from(&key[..]), v)),
-                    None => None,
-                }
+                CFPropertyList::downcast_into::<CFArray>(cfpl_value)
+                    .map(|v| (CFString::from(&key[..]), v))
             })
             .collect();
         let dictionary_cfpl = CFDictionary::from_CFType_pairs(pairs.as_slice());

dns_utility/src/netsh.rs

@@ -10,6 +10,7 @@ pub trait Netsh {
 #[derive(Default)]
 pub struct NetshCommand {}
 
+#[allow(clippy::upper_case_acronyms)]
 #[derive(Debug)]
 pub enum NetshError {
     NonZeroExit(i32),

masq/Cargo.toml

@@ -8,15 +8,16 @@ description = "Reference implementation of user interface for MASQ Node"
 edition = "2018"
 workspace = "../node"
 
-# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html
+# See more keys and their definitions at  https://doc.rust-lang.org/cargo/reference/manifest.html
 
 [dependencies]
 clap = "2.33.1"
+crossbeam-channel = "0.5.0"
 lazy_static = "1.4.0"
+linefeed = "0.6.0"
 masq_lib = { path = "../masq_lib" }
-rustyline = "7.1.0"
+regex = "1.0.5"
 websocket = {version = "0.26.0", default-features = false, features = ["sync"]}
-crossbeam-channel = "0.5.0"
 
 [lib]
 name = "masq_cli_lib"

masq/ci/unit_tests.sh

@@ -5,5 +5,6 @@ CI_DIR="$( cd "$( dirname "$0" )" && pwd )"
 export RUST_BACKTRACE=full
 export RUSTFLAGS="-D warnings"
 pushd "$CI_DIR/.."
-cargo test --release -- --nocapture --skip _integration --test-threads=1
+
+cargo test --release -- --nocapture --skip _integration
 popd