mirror of
https://github.com/OMGeeky/tarpc.git
synced 2025-12-29 07:40:14 +01:00
1089415451
-- Connection Limits The problem with having ConnectionFilter default-enabled is elaborated on in https://github.com/google/tarpc/issues/217. The gist of it is not all servers want a policy based on `SocketAddr`. This PR allows customizing the behavior of ConnectionFilter, at the cost of not having it enabled by default. However, enabling it is as simple as one line: incoming.max_channels_per_key(10, ip_addr) The second argument is a key function that takes the user-chosen transport and returns some hashable, equatable, cloneable key. In the above example, it returns an `IpAddr`. This also allows the `Transport` trait to have the addr fns removed, which means it has become simply an alias for `Stream + Sink`. -- Per-Channel Request Throttling With respect to Channel's throttling behavior, the same argument applies. There isn't a one size fits all solution to throttling requests, and the policy applied by tarpc is just one of potentially many solutions. As such, `Channel` is now a trait that offers a few combinators, one of which is throttling: channel.max_concurrent_requests(10).respond_with(serve(Server)) This functionality is also available on the existing `Handler` trait, which applies it to all incoming channels and can be used in tandem with connection limits: incoming .max_channels_per_key(10, ip_addr) .max_concurrent_requests_per_channel(10).respond_with(serve(Server)) -- Global Request Throttling I've entirely removed the overall request limit enforced across all channels. This functionality is easily gotten back via [`StreamExt::buffer_unordered`](https://rust-lang-nursery.github.io/futures-api-docs/0.3.0-alpha.1/futures/stream/trait.StreamExt.html#method.buffer_unordered), with the difference being that the previous behavior allowed you to spawn channels onto different threads, whereas `buffer_unordered ` means the `Channels` are handled on a single thread (the per-request handlers are still spawned). Considering the existing options, I don't believe that the benefit provided by this functionality held its own.
35 lines
950 B
TOML
35 lines
950 B
TOML
[package]
|
|
name = "tarpc-example-service"
|
|
version = "0.6.0"
|
|
authors = ["Tim Kuehn <tikue@google.com>"]
|
|
edition = "2018"
|
|
license = "MIT"
|
|
documentation = "https://docs.rs/tarpc-example-service"
|
|
homepage = "https://github.com/google/tarpc"
|
|
repository = "https://github.com/google/tarpc"
|
|
keywords = ["rpc", "network", "server", "microservices", "example"]
|
|
categories = ["asynchronous", "network-programming"]
|
|
readme = "../README.md"
|
|
description = "An example server built on tarpc."
|
|
|
|
[dependencies]
|
|
json-transport = { package = "tarpc-json-transport", version = "0.1", path = "../json-transport" }
|
|
clap = "2.0"
|
|
futures-preview = { version = "0.3.0-alpha.17", features = ["compat"] }
|
|
serde = { version = "1.0" }
|
|
tarpc = { version = "0.18", path = "../tarpc", features = ["serde1"] }
|
|
tokio = "0.1"
|
|
env_logger = "0.6"
|
|
|
|
[lib]
|
|
name = "service"
|
|
path = "src/lib.rs"
|
|
|
|
[[bin]]
|
|
name = "server"
|
|
path = "src/server.rs"
|
|
|
|
[[bin]]
|
|
name = "client"
|
|
path = "src/client.rs"
|