The rtc::remote attribute make a compilation error when used on a trait with lifetimes. This happen for example when using a Cow as return type to avoid unnecessary allocations.

Example

#[rtc::remote]
pub trait ExampleBorrowed {
    async fn hello(&self) -> Result<Cow<'_, String>, CallError>;
}

error[E0106]: missing lifetime specifier
  --> transport/src/cache.rs:45:41
   |
45 |     async fn hello(&self) -> Result<Cow<'_, String>, CallError>;
   |                                         ^^ expected named lifetime parameter
   |
help: consider introducing a named lifetime parameter
   |
43 ~ 'a, #[rtc::remote]
44 | pub trait ExampleBorrowed {
45 ~     async fn hello(&self) -> Result<Cow<'a, String>, CallError>;
   |

The compiler expect a named lifetime, while it can be elided in this case. When a named lifetime is provided, another compile errors occurs.

#[rtc::remote]
pub trait ExampleBorrowed {
    async fn hello<'a>(&self) -> Result<Cow<'a, String>, CallError>;
}

error: expected parentheses
  --> transport/src/cache.rs:44:19
   |
44 |     async fn hello<'a>(&self) -> Result<Cow<'a, String>, CallError>;
   |    

#[rtc::remote]
pub trait ExampleBorrowed<'a> {
    async fn hello(&self) -> Result<Cow<'a, String>, CallError>;
}

error: lifetime in trait object type must be followed by `+`
  --> transport/src/cache.rs:43:27
   |
43 | pub trait ExampleBorrowed<'a> {
   |                           ^^

error: expected at least one type
  --> transport/src/cache.rs:42:1
   |
42 | #[rtc::remote]
   | ^^^^^^^^^^^^^^
   |
   = note: this error originates in the attribute macro `rtc::remote` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0782]: trait objects must include the `dyn` keyword
  --> transport/src/cache.rs:43:27
   |
43 | pub trait ExampleBorrowed<'a> {
   |                           ^^
   |
help: add `dyn` keyword before this trait
   |
43 | pub trait ExampleBorrowed<dyn 'a> {
   |                           +++

error[E0224]: at least one trait is required for an object type
  --> transport/src/cache.rs:43:27
   |
43 | pub trait ExampleBorrowed<'a> {
   |   

serde_cbor is no longer maintained since August (see the repository README and RUSTSEC-2021-0127). I suggest replacing it with ciborium which is actively maintained and recommended by the author of serde_cbor as an alternative.

However, ciborium has made different design choices that make it incompatible in some cases with serde_cbor. This may cause errors if the client and server does not use the same version of remoc.

I have been experimenting howto create a persistent service. See https://github.com/janjaapbos/remoc-test

I managed to achieve some results with this example.

In one terminal: cargo run --bin server_owner

In another terminal repeatedly: cargo run --bin client

Does this approach make sense at all? What would you advise for best practice?

Originally posted by @janjaapbos in https://github.com/ENQT-GmbH/remoc/discussions/1#discussioncomment-1692799

Hello! I noticed that your current CI workflow takes a lot of time to run. This PR improves it:

• Each step has been separated in different jobs (with matrix jobs for tests). This allows to run task concurrency, and makes the workflow easier to understand.
• Dependencies are cached with Swatinem/rust-cache and baptiste0928/cargo-install to speed up workflows.
• Clippy is also run on tests (I fixed few lints)

With these improvements, the workflow takes only 12 minutes to complete, vs. half an hour with the current one.

This PR contains a lot of useless commits, I suggest you to squash-merge the PR instead of a regular merge.

I noticed that release changelog is only available in the CHANGELOG.md file. I think it would be nice to publish them as GitHub releases too, as this allows you to quickly see when the last version was made and therefore if the project is active. It also allows people interested in remoc to watch releases and get notified when a new version is available.

First, thanks for this great crate! It seems like it is exactly the abstraction I needed.

I'm currently refactoring some code to using remoc. However, one of my test cases was spuriously failing. I tracked it down to my usage of the Distributor API. A very simplified example looks like this:

  use remoc::rch::mpsc::{self, channel};

  pub type Sender<T> = mpsc::Sender<T, remoc::codec::Bincode>;
  pub type Receiver<T> = mpsc::Receiver<T, remoc::codec::Bincode>;

  async fn send_task(sender: Sender<()>) {
      for _ in 0..16 {
          sender.send(()).await.unwrap();
      }
  }

  async fn receive_task(receiver: Receiver<()>) {
      let distributor = receiver.distribute(false);
      for _ in 0..16 {
          let (mut receiver, handle) = distributor.subscribe().await.unwrap();
          receiver.recv().await.unwrap().unwrap();
          dbg!("Received value");
          handle.remove();
      }
  }

  #[cfg(test)]
  mod tests {
      use super::*;

      #[tokio::test]
      async fn lost_messages() {
          let (sender, receiver) = channel(64);
          tokio::join!(send_task(sender), receive_task(receiver));
      }
  }

The test case fails with a panic on the second unwrap of receiver.recv().await.unwrap().unwrap(); in the receive_task after a few iterations. I've looked at the source code and it seems, that the distributor continuously tries to get a permit for one of the DistributedReceivers and then recvs a message on the original receiver which is sent to the permit.

I expected the Distributor to effectively turn the mpsc channel into a mpmc channel. But the behaviour is different in a crucial way. With an mpmc channel like the one offered by async_channel items can't be lost by receivers for which recv is not called.

    use async_channel::{Receiver, Sender};

    async fn send_task(sender: Sender<()>) {
        for _ in 0..16 {
            sender.send(()).await.unwrap();
        }
    }

    async fn receive_task(receiver: Receiver<()>) {
        for _ in 0..16 {
            let receiver_clone = receiver.clone();
            receiver_clone.recv().await.unwrap();
            dbg!("Received value");
        }
    }

    #[cfg(test)]
    mod tests {
        use super::*;

        #[tokio::test]
        async fn no_lost_messages() {
            let (sender, receiver) = async_channel::bounded(64);
            tokio::join!(send_task(sender), receive_task(receiver));
        }
    }

I'm not sure how or if this behaviour could be changed. If this is the expected behaviour of the distributor, it should probably be clarified in the docs.

I've created a repo here with the code samples to reproduce.

When trying to use remoc on browser, it panics because it calls tokio::time::timeout, which is based on tokio::time::Instant::now, which in turns calls std::time::Instant, which is not supported on browser. Could you consider replacing it with an implementation that supports both tokio::time (on supported platforms) and wasm time (on browsers)? For instance, please take a look at https://crates.io/crates/instant implementation.

Question above :) Hope this is a good place to ask!

My use case: I have an remoc::rtc server and I want to use the client-side connection from multiple places in the code. As long as the trait has only methods with a &self receiver, the Client is Clone and so I can just .clone() it to share access to it. If I have &mut self methods, then it's not Clone any more... now I'm thinking... does this mean that the Client impl does synchronization on the client side? I would have expect the server to be solely responsible for synchronizing access to its &mut self methods, is that not the case?

EDIT: I also cannot find where in the code it gets decided whether or not the Client will be made Clone, as well as the actual impl of the client. But I'm not used to working with heavy macro usage, so I'm sure I'm just missing the obvious :) EDIT 2: Found where it's determined, don't understand why just yet.

And thanks for making this create, it's quite awesome! Hoping to contribute something of value to it once I've got it in production. e.g. I'm noticing that CallError is not user-extensible, so I can't pass along my own errors from rtc methods, which seems unnecessarily limiting (except that of course each feature needs effort in terms of thinking + impl + maintenance!).

I think it might be interesting to add benchmarks to get an idea of remoc performance and avoid regressions. This could be done with criterion since it supports async benchmarks.

Benchmarks could also be made to compare remoc to other similar libs like tarpc and with a raw TCP socket (to get an idea of the performance overhead introduced by remoc).

Hello! While using Remoc in my application, I realized that some connection logic was duplicated:

• I need to implement some basic connection logic each time I create a server/client type. This includes for example graceful shutdown or automatic reconnection.
• I use Remoc to communicate between multiple services, where each service handles a single task. Therefore, all my Remoc servers send a channel or a rtc client as soon as the connection is created. Other channels may be created later, but the base channel is only used to send a more appropriate type.

I think these use cases are quite common, so I propose to include types to make their implementation easier:

• Allow to initialize a connection with other types than base channel, for example directly with an RPC server/client or a broadcast channel. Maybe create Handler traits with methods that will be called directly after a connection is established.
• Implement generic Client and Server types that are configured with a specific transport and handler, and manage the connection. This includes graceful shutdown and automatic reconnection, for example.
• Abstract transports with a Transport trait, that could be used in Connect or directly with a Server/Client. Implementation for common transports such as TCP may be provided.

Built-in handlers for common usages such as RPC or broadcasting stream may be provided.

I think adding features like this would make remoc much easier to use by hiding some things that may seem complex to beginners, without sacrificing the flexibility of the library, since all these features would be optional, and could even be used partially. Remoc is a project that can be useful to many people and fulfills many use cases. Making it easier to get started with would in my opinion make it much more used and would make it a serious alternative to tarpc or tonic.