47a6235414 | ||
---|---|---|
.. | ||
cbindings | ||
cpp | ||
golang | ||
mobile | ||
nodejs | ||
python | ||
rust | ||
wakustealthcommitments | ||
README.md | ||
filter_subscriber.nim | ||
lightpush_publisher.nim | ||
nim.cfg | ||
publisher.nim | ||
subscriber.nim |
README.md
Examples
Compile
Make all examples.
make example2
## basic2
TODO
## publisher/subscriber
Within examples/
you can find a publisher
and a subscriber
. The first one publishes messages to the default pubsub topic on a given content topic, and the second one runs forever listening to that pubsub topic and printing the content it receives.
Some notes:
- These examples are meant to work even in if you are behind a firewall and you can't be discovered by discv5.
- You only need to provide a reachable bootstrap peer (see our fleets)
- The examples are meant to work out of the box.
- Note that both services wait for some time until a given minimum amount of connections are reached. This is to ensure messages are gossiped.
Run:
Wait until the subscriber is ready.
./build/subscriber
And run a publisher
./build/publisher
See how the subscriber received the messages published by the publisher. Feel free to experiment from different machines in different locations.
resource-restricted publisher/subscriber (lightpush/filter)
To illustrate publishing and receiving messages on a resource-restricted client,
examples/v2
also provides a lightpush_publisher
and a filter_subscriber
.
The lightpush_publisher
continually publishes messages via a lightpush service node
to the default pubsub topic on a given content topic.
The filter_subscriber
subscribes via a filter service node
to the same pubsub and content topic.
It runs forever, maintaining this subscription
and printing the content it receives.
Run Start the filter subscriber.
./build/filter_subscriber
And run a lightpush publisher
./build/lightpush_publisher
See how the filter subscriber receives messages published by the lightpush publisher.
Neither the publisher nor the subscriber participates in relay
,
but instead make use of service nodes to save resources.
Feel free to experiment from different machines in different locations.