RFC: server to client event/notification system about tarpc HOT 24 CLOSED

I can see how some sort of sugar for this would be useful, but it's probably out of scope for tarpc, at least for now. You can do this already, though, with a pair of subscriber/publisher services. I thought it'd make for an interesting example, so I whipped up one.

from tarpc.

This pattern can work in some cases, but there are major issues in some other (e.g. public API). It requires that the server has knowledge of the client's API or that clients implement a generic callback/server trait. But even then, the clients behind a NAT (mobile phones), would need to use UPNP to punch holes in the NAT and be able to listen (I'm not sure if a mobile phone's allowed to do that, probably not). They would also need an auth system to know that the connections really come from the server and not a malicious party.

from tarpc.

I don't think it requires knowing anything about the client's API or using a generic callback trait. The subscriber service could be separate from any other clients it's being used with. i.e. you could make an rpc from some other clients in response to a push notification.

An auth system is probably going to be required for most applications anyway, but it's also out of scope, at least for now.

from tarpc.

I don't think the library needs an auth system, it was just to illustrate a point. What do you think of the issues related to the client having to open and bind a socket (NAT traversal)?

from tarpc.

My expectation is that most clients will be running on servers, where this wouldn't be an issue. Admittedly tarpc isn't mobile-focused, but I also would like to do what I can to support it. Does your specific use case involve mobile apps? Is having to bind a socket in a client-only application a showstopper for you?

from tarpc.

I don't have a specific case at the moment, but I want to make projects using Rust as a backend for websites and services. If the library could encode messages as JSON instead of bincode and a WebSocket transport was added, browsers would be able to connect directly to tarpc. Mobile apps would be able to connect to tarpc via WebSocket or plain TCP.

Both web and mobile applications would benefit from not having to create a server.

from tarpc.

Regarding JSON, we're definitely planning to be generic over serialization protocol. Just haven't got around to it yet (lots of things to work on :).

I do see your point. The scope of events seems relatively constrained; it wouldn't be hard to add support for it. I fear feature creep, though, and this wasn't a use case we'd originally intended to support. Also, pedagogically it's not that easy to explain when you'd use it. But let me think about it some more.

from tarpc.

There is a feature creep danger, I agree. For instance, I was thinking that this could be used to create a chat application. One issue I noticed, is that if you have events coming from a channel, you don't want to send the events to all the listeners, only the ones connected to the channel. So this would require a way of filtering clients before broadcasting, and it's kind of a Pandora's box.

from tarpc.

Yeah, I'd definitely like to see how far we can get with the current feature set (plus some known outstanding things like serialization-protocol agnosticism) before deciding to add something like this. I'd love to get feedback from real usage; I encourage you to see what you're able to do with tarpc in its current form!

from tarpc.

@sbstp I think your use case can be handled by supporting streaming RPCs. A subscriber could open a stream to the server, and the server could stream back anything that was published. This is something we've thought about but not put much effort into thus far. It should get done, just not sure how fast.

from tarpc.

futures-rs has a nice Stream abstraction. I think it's likely we'll want to use that for something like this.

from tarpc.

More information on the Stream trait.

from tarpc.

Is it worth investing in futures given generators could be implemented in the coming months?

from tarpc.

The futures crate is being championed by the core team, and IMO it's likely
to be forward compatible with generators. I also very much like the
ergonomics of the futures as existing now, and we don't know when any
alternative will come in the future (no pun intended).

TLDR: I'm happy to pay the price of being an early adopter.

On Wed, Aug 10, 2016, 12:13 PM Simon Bernier St-Pierre <
[email protected]> wrote:

It it worth investing in futures given generators could be implemented in
the coming months?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#39 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/ACx9wVNfGOJ6nFo3oNwoinMC-kqYLgrHks5qeiLugaJpZM4InE6e
.

from tarpc.

Another usecase: I'm developing a game in Rust, and server collects input from clients and send them back the physical world updates. It's not that uncommon to encounter a client behind NAT so it will be really great if I can reuse the established connection, for server to call client.

How about supporting server-calling-client-API through the established connection. I think this bi-directional calling is general enough to be implemented at RPC lib layer. Socket IO supports that, for example. And event-notification can be built upon that separately.

from tarpc.

That definitely sounds like a valid use case! Adam and I talked a bit about the design a while back, but we never made real forward progress. I'm happy to revisit it, but I don't have a ton of bandwidth in the upcoming weeks to do a deep dive. I want to represent this as an RPC that returns a Stream. Maybe even support multiple streams per RPC, I don't know. And also allow them to be bidirectional.

from tarpc.

I think streaming and bi-directional call should be treated independently. For now, I'm using grpc (which supports streaming but not reverse-call), and squeezing all server-calling-client-API to a stream. And that's an ugly hack. To illustrate, there is one stream opened that gets server msgs

enum ServerMsg {
    PlayerMoved {player_id: u32, x:f32, y:f32, z:f32},
    PlayerJumped {player_id: u32},
    GamePaused,
    ...
}

Where each msg type deserves separate RPC definitions ideally.

from tarpc.

Ah, I see what you're saying. Is there any prior art for that kind of thing? I'm a bit nervous about intermixing client/server roles. There's another open issue for communicating to multiple services over a single connection. Maybe that would better serve your needs? Though admittedly that's also a feature that I don't expect to implement any time soon as it feels like it's better suited to the tokio layer. But I haven't thought about it a ton.

from tarpc.

Maybe it's more cleaner layering in this way? It's not server-calling-client but creating a service through an abstracted connection layer, which initiation is implementation detail. So we will introduce an abstract connection layer(Trait) and provide two impls:

• TCP connection stream impl
• Stream multiplex component that takes another stream impl and provides N abstract streams (by tagging or whatever).

And a service will be on a stream. And two streams will be needed in my case. In this way, supporting multiple services is also very natural.

from tarpc.

Btw, it looks like https://github.com/kmcallister/urpc generalizes service over Read + Write Trait. I think it makes sense because then one can plug any transport layer they want, IPC, UDP+KCP, Websocket, etc...

If tarpc supports that abstraction, it will be easy to implement the above without modifying tarpc, by just writing multiplexed stream component separately.

from tarpc.

We probably could abstract over AsyncRead and AsyncWrite. I'd file a separate issue for that!

from tarpc.

Thanks! =D

from tarpc.

Do you have a plan to implement this in tarpc?
Or should I multiplex one stream to multiple streams and establish multiple tarpc sessions?

from tarpc.

I'm pretty sure I won't do this in a first class way, because the best way to do that would be by supporting streaming RPCs, and I'm loathe to do that because it'd basically just end up as a worse HTTP2. I think I like the niche tarpc fills of a simple request-response abstraction.

I suppose that means I should close this issue. ;)

from tarpc.