This crate requires a nightly (unstable, experimental) compiler version. To switch to it, you must have Rust installed via Rustup, and run:

rustup default nightly

Run rustup default stable to switch back.

Adding `discotech` library as a dependency

Run this command in a terminal, in your project's directory:

cargo add discotech

To add it manually, edit your project's Cargo.toml file and add to the [dependencies] section:

discotech = "0.0.3"

The discotech library will be automatically available globally.

Back to the crate overview.

Readme

Discotech 🌐

The perfect place to connect with that special service.

The Dill Pickle

Discotech is what happens when engineers who have used distributed systems see existing open source service discovery and load balancing mechanisms and throw up in their mouths a little bit.

DNS A-records are good for efficient distribution of names to TTL-respecting or short-lived clients. Most open source infrastructure ignores DNS TTL's. Engineers know how to write exponential backoffs, but they rarely re-resolve when their backend is unavailable. If they do re-resolve during failure, but a back-end is only partially unavailable, you can have split configuration across your infrastructure until a deconfigured partially unavailable service is fully disabled. A-records do not contain port information, so identical ports across all instances of a backend are common, imposing additional constraints on operation and utilization.
The use of a local proxy/ambassador is nice in cases where you want to centralize your local service discovery and load balancing logic. Typically a local proxy will listen on a port for a local client to connect and send a request, which will then be forwarded to a selected downstream. In some cases local clients will try to connect to "some-service.some-cluster.some-dc.some-domain.some-tld" and a DNS system will return a specific magic IP address that triggers a forwarding rule (possibly using iptables/nftables/ipfw/pf/etc...) to forward to local-host:service-specific-port where the local proxy is listening. Some proxies use zero-copy mechanisms like splice(2) to avoid a performance hit caused by copying the request. There is still some added overhead, as every write to the socket from the client requires waiting on the proxy to be notified of new data and then calling splice. The proxy is not able to intelligently set SPLICE_F_MORE as it doesn't know when the client is done sending, causing some optimization techniques to become impossible. Another problem is you still need an external mechanism for mapping a desired service to a local proxy port.
The use of forwarding logic like iptables is fine when you will only ever have a single back-end, and you require no load balancing logic. Otherwise you will need to rely on external mechanisms.

Discotech is helpful malware - hooking getaddrinfo and connect. This allows for all kinds of high-performance and flexible patterns:

service discovery
load balancing
connection prefetching
SRV-over-A by mapping from some SRV address -> magic ip in the getaddrinfo hook, and in the connect hook swapping the magic ip and arbitrary port to those for a selected back-end.

Configuration

Strives to avoid unavailability amplification due to problems in adjacent layers
Receives updates from a configurable source: ZK, DNS SRV, flat files, etc...
Ignores sharp drops (false-deconfiguration)
Caches last known good results

Adding discotech library as a dependency

Adding `discotech` library as a dependency