Interested in Zebus ?
This room is not really active indeed but we're pretty responsive on Github
You can talk here or submit an issue if you think it's more appropriate
Thanks for responding. I don't think my questions are appropriate for an issue, per se. I'm trying to implement Zebus, but I'm just not sure where to start. I've read and re-read the Quick Start and successfully used the samples. But there doesn't seem to be quite enough documentation in the samples and readme to get me going on a project we can use in production. Is there some more extensive documentation available? Or is the expectation that one reads the code and figures things out?
Right now, my main two questions are: How do I implement the Directory? And: How do I ensure that the Directory uses Cassandra for persistence? I'll keep experimenting, but I'm just not clear on those two things. I really wish there were an API reference with explanations beyond the raw method signatures.
Hello. You do not have to "implement" Zebus or the Directory. But you need to run a Zebus Directory in order to start Zebus clients. You can compile and run
Abc.Zebus.Directory.Runner. There are two persistence modes for the Directory: in-memory (single-instance only, unsafe) and Cassandra (multi-instance supported). There is also work in progress to provide a RocksDB persistence mode (single-instance only but safer that in-memory and simpler to deploy).
To activate the Cassandra persistence, you need to create the schema using schema_creation.cql.
The
Storage configuration must be changed to Cassandra. You also need to specify the Cassandra.* configurations.
@ocoanet So far, so good. I am mostly there, but working through dependency issues with Newtonsoft.Json. But another question I have is related to security. Is there any equivalent in Zebus to WCF's binding that allows you to secure the Transport? That is, does Zebus traffic necessarily always run over TCP in plain text? Or is there a way to secure the traffic via TLS?
There is no option to secure the network traffic right now. Because Zebus is zmq-based, I suppose that we can easily add settings to enable zmq_curve if this helps.
Ok I see. As far as I am aware there is no way to make zmq FIPS compliant. If you are really interested in using Zebus, there might be a last option. I implemented a nng transport for Zebus in a branch. I did not merge it into master because it was incompatible with zmq and because the performance was not as good as zmq. But nng supports TLS .
There is also work in progress to provide a RocksDB persistence mode
Is the RocksDB persistence mode something I can implement now? Or does it need more work? I've gotten Zebus working insofar as I'm creating the Directory, starting the bus, and transferring data. Now I need to get the persistence working, but I don't want to use Cassandra if I can use something simpler.
The RocksDb as backing storage for the Directory branch is still a WIP (https://github.com/Abc-Arbitrage/Zebus/tree/directory-rocksdb). However, the RocksDb storage for the Persistence component is currently implemented (but not production tested).
I think I am misunderstanding something about the Directory. When you say that the in-memory Directory is "single instance," do you mean that there can be only one instance of it running on the network and accessed by the clients? (Only one Directory endpoint?) I've been trying to host an instance of the Directory on every peer, but this is not working. The event handlers fire only on the host device and are not propagated to the peers. Could this be because I've got more than one instance of the Directory running on the network?
@daryljlucas you don’t need one Directory per peer, you just need enough instances to satisfy your desired level of fault tolerance. For example we have 3 Directory instances running in production and development.
This only applies to Directories using Cassandra for storage as the in-memory storage is single instance only so you would only need one for all your peers.
This only applies to Directories using Cassandra for storage as the in-memory storage is single instance only so you would only need one for all your peers.
I know that running an instance of the Directory on every peer is not a requirement for Zebus. It is a requirement for our use case. In our situation, the network is set up and taken down within a single day by ordinary users. There are no servers, nor can there be any specially-designated machines that a user has to designate as a "Directory host". All peers have to be equal in terms of their role in the network so that none of them is essential to the others. This means that if the peers are going to have access to a Directory, they have to know that any of their peers can have a copy, since there is no guarantee that any other specific peer will exist an hour later. I guess the bottom line question I have is: Why would any of these Directories not find the peers that are handling the Publish calls on the bus? The peers call Publish on the bus, but the even handlers fire only on the sending peer. I had a simpler version of this working a couple of weeks ago, but now that I'm integrating with our application I'm getting this unexpected behavior, and I'm not sure why. I think it's because there is something about the Zebus architecture that I'm not understanding properly.
Zebus is not fully de-centralised with regard to discovery of peers. When a peer starts it will try to register on one, and only one, of it's configured Directories and that Directory will then publish to all existing known peers. The Directory has no other way of discovering peers (including other Directories).
This is why we said that an in-memory storage Directory is single-instance as it's internal state would only reflect those peers that have registered with it and ignore all other peers that have registered with other Directories. When Cassandra is used as a backing store the Directories synchronise their internal state via Cassandra thus providing a complete view of the peers / subscriptions active on the network.
This is why we said that an in-memory storage Directory is single-instance as it's internal state would only reflect those peers that have registered with it and ignore all other peers that have registered with other Directories. When Cassandra is used as a backing store the Directories synchronise their internal state via Cassandra thus providing a complete view of the peers / subscriptions active on the network.
OK, so that means that I really need to use Cassandra as a backing store to get the synchronization. That makes sense. I was hoping to do the simple case first before going to Cassandra, but I clearly need to use it. (We don't use Cassandra for anything else, so there's a learning curve for me there.) Thank you for your help -- I greatly appreciate it!
Maybe I just don't understand Cassandra. The core requirement is for a location to be brought up by ordinary users with 3 to 16 nodes that can transfer a specific set of data between each other throughout the day, data that is being created throughout the day on each of the peers. There's no way to know ahead of time what the IP addresses will be. Any peer can be removed at any time and replaced with another.
We have been using WCF's peer-to-peer netPeerTcpBinding (which uses PNRP for name resolution) for years, but it has serious problems of its own and has been obsoleted by MS, so we need a replacement. Zebus seems to be one of our best options because of its apparently truly peer-to-peer nature and high performance. At the end of the day, this network of peers must not require the skills of a technical expert, and it must be flexible enough not to require designation of a single device as a "master." And all setup and teardown must happen inside of a single day.
To be explicit, I'm talking about a polling place -- a place where people vote.
I’m not talking about DNS, I’m talking about how different peers find out about each other’s existence on a network. There is quite a lot of literature on the subject and some implementations (Bitcoin, BitTorrent, etc...) but even those implementations have some bootstrapping configuration.
Neither Zebus nor Cassandra have a zero-configuration setup.
Neither Zebus nor Cassandra have a zero-configuration setup.
Currently you need to provide each peer with one or more Directories at start-up so they need to be well-known.
If a Directory uses Cassandra, a cluster must be configured and one or more of the nodes needs to be provided to the Directory at start-up - nodes are well-known again. In addition to this Cassandra does not have any way of dynamically detecting new nodes, the cluster configuration is done statically. Every new node must have “seed” nodes provided at start-up.
If a Directory uses Cassandra, a cluster must be configured and one or more of the nodes needs to be provided to the Directory at start-up - nodes are well-known again. In addition to this Cassandra does not have any way of dynamically detecting new nodes, the cluster configuration is done statically. Every new node must have “seed” nodes provided at start-up.