|Tony Garnock-Jones a74cd19526||2 weeks ago|
|dev-scripts||4 months ago|
|docker||1 year ago|
|syndicate||2 weeks ago|
|syndicate-macros||4 weeks ago|
|syndicate-server||4 months ago|
|syndicate-tools||4 months ago|
|.gitignore||5 months ago|
|Cargo.lock||4 weeks ago|
|Cargo.toml||8 months ago|
|Cross.toml||2 years ago|
|Makefile||4 weeks ago|
|README.md||2 years ago|
|fixtags.sh||1 year ago|
|rust-toolchain||2 years ago|
|syndicate-rs-server.png||2 years ago|
A Rust implementation of:
the Syndicated Actor model, including assertion-based communication, failure-handling, capability-style security, dataspace entities, and facets as a structuring principle;
the Syndicate network protocol, including
a high-speed Dataspace indexing structure (
skeleton.rs; see also HOWITWORKS.md from
a standalone Syndicate protocol "broker" service (roughly comparable in scope and intent to D-Bus); and
a handful of example programs.
The Syndicate/rs server running.
git clone https://git.syndicate-lang.org/syndicate-lang/syndicate-rs cd syndicate-rs cargo build --release ./target/release/syndicate-server -p 8001
Running the examples
In one window, start the server:
./target/release/syndicate-server -p 8001
Then, choose one of the examples below.
Producer/Consumer (sending messages)
In a second window, run a "consumer" process:
Finally, in a third window, run a "producer" process:
State producer/consumer (state replication)
state-consumer, respectively, in the instructions of the previous
subsection to demonstrate Syndicate state replication.
Pingpong example (latency)
In a second window, run
and in a third window, run
The order is important - the difference between
about who kicks off the pingpong session.
You may find better performance by restricting the server to fewer cores than you have available. For example, for me, running
taskset -c 0,1 ./target/release/syndicate-server -p 8001
roughly quadruples throughput for a single producer/consumer pair, on my 48-core AMD CPU.