intiface / intiface-cli-rs Goto Github PK

intiface-cli-rs should only allow one connection at a time, and shouldn't crash when insecure connections are tried against secure ports and vice versa.

We can see when we get the ServerInfo message, but we don't currently have a way to send the client name to the GUI. Need to figure this out.

STR

1. Open Intiface desktop
2. Start server
3. Connect with a client
4. Disconnect client
5. Reconnect client

Expected
Desktop icon is green at end

Actual
Desktop icon is red

STR:

1. Run intiface-cli on Linux with --stayopen and websockets
2. Connect and disconnect a client

Expected:

CLI stays running

Actual:

CLI stops because it can't rebind to the server port

Notes:

This may have to do with the rejection server in the CLI?

Process should close on client disconnect when --stayopen is not used, but currently does not.

It doesn't happen linearly, rather it looks fine with memory usage in the 10's of MB for a long time until it suddenly spirals and grows. It seems to demand a lot of CPU time as well as this is happening.

another instance

I'm not sure if this is what causes it to happen, but I run scanning in a 5 second loop like this from the C# library, and if I increase the timeout to 60 seconds instead of 5 it doesn't seem to spiral out of control. Either that or the effect is just delayed by 12 times so I haven't had a chance to experience it...

mClient.StartScanningAsync();
await Task.Delay(1000);
mClient.StopScanningAsync();

In my attempts to test the btleplug/buttplug libraries, I grabbed this project to try to quickly get myself up and running.
I've currently got ca76f78 (v23) and I've modified the Cargo.toml to use a local development copy of buttplug-rs as well as a local development copy of btleplug.

Expected behaviour

Running cargo run -- --wsallinterfaces would sping up an insecure Intiface server to test with uing default ports that is commonly associated with Intiface (12345, 12346)

Actual Behaviour

main' panicked at 'assertion failed: !ret.inner.is_empty()', /home/nzsmartie/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-util-0.3.8/src/future/select_all.rs:40:5

This happens in:
buttplug-rs panics in buttplug-rs/buttplug/src/connector/transport/websocket/websocket_server.rs::impl ButtplugConnectorTransport for ButtplugWebsocketServerTransport::connect()

    Box::pin(async move {
      *disconnect_sender.lock().await = request_sender.clone();
      if let Err(connector_err) = select_all(tasks).await.0 {
        Err(connector_err)
      } else {
        Ok((request_sender, response_receiver))
      }
    })

select_all asserts that tasks is not empty. However, since neither the port for an insecure websocket or secure websocket was provided, no websocket future tasks were added to tasks. causing the assertion to trigger.

Using rustup and the default toolchain:

cargo +stable-x86_64-unknown-linux-gnu install intiface-cli

ultimately fails with

   Compiling git2 v0.15.0
   Compiling intiface-cli v50.0.0
error: failed to run custom build command for `intiface-cli v50.0.0`

Caused by:
  process didn't exit successfully: `/tmp/cargo-installi2JrcJ/release/build/intiface-cli-8cd53a1f867a084a/build-script-build` (exit status: 101)
  --- stderr
  thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: could not find repository from '/home/natalie/.cargo/registry/src/github.com-1ecc6299db9ec823/intiface-cli-50.0.0'; class=Repository (6); code=NotFound (-3)', /home/natalie/.cargo/registry/src/github.com-1ecc6299db9ec823/intiface-cli-50.0.0/build.rs:9:18
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...

Interestingly it does succeed if I clone this repo and do a cargo build instead. So maybe this is something about how this package is published?

It would be good if it could be installed directly, since the released binaries don't work well on linux. There are too many different configurations and I can't get it to work on Ubuntu 22.04 without rebuilding it locally. There is a hack for making libssl.so.1.1 work there but it will kinda mess up the system.

If an unsuccessful connection happens while the process is running with --stayopen, the process will exit, which looks like a crash to Intiface Desktop.

We need a way to set the port for the websocket device server.

Argument errors happen before we even know if we have a frontend pipe, meaning we can lose a process on argument errors with no useful logs.

For Big Sur, we need an Info.plist file sitting next to the CLI for bluetooth permissions.

Race condition somewhere in the IPC handling for shutdowns. We get the message that the token should have been cancelled, but the event loop itself does not shut down.

This will require UI on the desktop side, but we should be able to see currently connected devices in Intiface Desktop

After a few times closing + restarting some scripts, I noticed the Rust server would stop accepting connections if the connection was not closed gracefully too many times.

Steps to reproduce:

1. Run Intiface's Rust server
2. Run a script that connects to the server (e.g. the Python example)
3. Terminate that script with Ctrl+C, or otherwise end it in a non-graceful way
4. IntifaceCLI will display an error such as:

thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: Protocol("Connection reset without closing handshake")', /home/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/buttplug-0.7.2/src/connector/transport/websocket/websocket_server.rs:59:5

5. Continue doing this several more times.
6. After 5 or so attempts, the script will fail to connect to the server anymore.

Could not connect to server, exiting: [Errno 111] Connect call failed ('127.0.0.1', 12345)

The server appears to accept new connections if they are all closed gracefully, but not if they are non-graceful.

Expected behavior:

The server would continue to accept new connections.