Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Antoine Blanchet
    @ablanchet
    :sparkles:
    Suminda Sirinath Salpitikorala Dharmasena
    @sirinath
    hi
    Kévin Lovato
    @alprema
    hi
    Interested in Zebus ?
    Mendel Monteiro-Beckerman
    @MendelMonteiro
    👋
    daryljlucas
    @daryljlucas
    Judging by the timestamps, it doesn't look like this chat room is active. But I'm hoping someone monitors it anyway, because I have questions about Zebus and don't see anywhere else to go for help.
    Romain Verdier
    @rverdier
    @daryljlucas Hello ; how can we help you?
    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
    daryljlucas
    @daryljlucas
    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?
    daryljlucas
    @daryljlucas
    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.
    Olivier Coanet
    @ocoanet
    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.
    Olivier Coanet
    @ocoanet
    Then you need to change the Directory App.config file to use Cassandra.
    The Storage configuration must be changed to Cassandra. You also need to specify the Cassandra.* configurations.
    daryljlucas
    @daryljlucas
    @ocoanet Thank you for that information! That is immensely helpful! I'll give that a go and let you know if I need anything more.
    daryljlucas
    @daryljlucas
    @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?
    Olivier Coanet
    @ocoanet
    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.
    daryljlucas
    @daryljlucas
    I'm not sure zmq_curve would do it. We service government agencies, and as such, the security has to be FIPS 140-2 compliant. It may be necessary for us simply to encrypt the messages.
    Olivier Coanet
    @ocoanet
    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 .
    daryljlucas
    @daryljlucas
    Being able to run the messaging using TLS would be ideal. How much of a departure from a normal Zebus rollout would your suggestion be?
    Olivier Coanet
    @ocoanet
    nng is very similar to zmq. The change from a normal Zebus would be very limited.
    daryljlucas
    @daryljlucas
    OK, that sounds great. What are the steps for making the change to nng?
    daryljlucas
    @daryljlucas

    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.

    Mendel Monteiro-Beckerman
    @MendelMonteiro
    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).
    daryljlucas
    @daryljlucas
    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?
    Mendel Monteiro-Beckerman
    @MendelMonteiro
    @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.
    daryljlucas
    @daryljlucas
    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.
    Mendel Monteiro-Beckerman
    @MendelMonteiro
    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.
    daryljlucas
    @daryljlucas
    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!
    Mendel Monteiro-Beckerman
    @MendelMonteiro
    No worries
    Mendel Monteiro-Beckerman
    @MendelMonteiro
    Please note that your proposed setup is quite different from what we use in production and therefore YMMV. How many Directories would you expect to run on your network at any one time?
    daryljlucas
    @daryljlucas
    Base case is 3 to 6 peers. Some large sites can have 12 to 16.
    Mendel Monteiro-Beckerman
    @MendelMonteiro
    Would the sites communicate with each other? Where were you thinking of hosting the Cassandra cluster?
    daryljlucas
    @daryljlucas
    Each site is independent. One cluster per site.
    Mendel Monteiro-Beckerman
    @MendelMonteiro
    There’s something I’m not getting about your requirements. You don’t want to have static directories configured per site but you can have a static Cassandra cluster configured per site...
    daryljlucas
    @daryljlucas
    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.
    daryljlucas
    @daryljlucas
    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.
    Mendel Monteiro-Beckerman
    @MendelMonteiro
    I’m not sure that Zebus will meet those requirements as it seems you need decentralised peer discovery and Zebus isn’t designed for that.
    daryljlucas
    @daryljlucas
    We don't need Zebus to do the name resolution. Pinging the network is sufficient for that. What we need is a mechanism for moving the data.
    Mendel Monteiro-Beckerman
    @MendelMonteiro
    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.
    Mendel Monteiro-Beckerman
    @MendelMonteiro
    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.
    daryljlucas
    @daryljlucas
    OK, then Zebus won't work for us. Thanks for all your help.