I see that the vertx example implementation has been moved out of the plumtree module now, nice.
I'm still trying to figure out whether a given gossip implementation should really be more of a reactive/async usecase than an EE/servlet sort of implementation. If a blocking call is acceptable for such an implementation then perhaps it should be more of a jaxrs API then a standard servlet. I also note that there is no MessageValidator implementation other than a stubbed out implementation that returns true. I am curious what sort of validations are envisioned for these usecases. A couple that come to mind: - message signature verification which would require a signature within the message as well as public keys or the like available to verify - field specific checking of the payload for bounds checks, checking that there are no embedded javascript or the like that could potentially be a XSS attack, etc - some notion of the sender in terms of client ip, etc It seems the plumtree library itself consists almost entirely of interfaces. I would expect at least some abstract implementations of MessageValidator, MessageSender, MessageListener, etc. I guess the gist is that State.java represents the entire framework that stitches the pieces together. Does this concept of State come directly from other epidemic broadcast trees? It seems odd to me that something called State actually sends and handles messages. I'd expect something representing the local "peer" to send and handle messages and set state on the State class. A class diagram and maybe flow diagram may make all of this more clear. The programming model consists of implementing all of the protocol, app specifics of the listeners, senders, validators, etc and injecting them into the State class. Perhaps a walk through that describes the vertx sample [1] will tease out the programming model that we can include on the Plumtree Tutorial page as a developer's guide? Thank you for your patience with me as I try to grok these pieces and the intended programming model! --larry 1. https://github.com/apache/incubator-tuweni/blob/main/plumtree-vertx/src/main/java/org/apache/tuweni/plumtree/vertx/VertxGossipServer.java On Mon, Dec 12, 2022 at 1:05 AM larry mccay <lmc...@apache.org> wrote: > Oh, that actually cleared up what the vertx package is in the plumtree > module. > I was a bit confused as to whether it was part of the implementation or > not. > > It does seem that vertx is only used within the example server and related > integration tests. > If this isn't required as part of the programming model then it would be > better to move it out, I think. > > The servlet implementation might be interesting. > I will give it some more thought. > > On Mon, Dec 12, 2022 at 12:30 AM Antoine Toulme <anto...@toulme.name> > wrote: > >> Yes, that is a valid use case! It’s just gossip and propagation, and as >> long as all servers know of at least a valid peer, they can propagate the >> information. >> >> Definitely happy to help with a tutorial page and push this component to >> maturation. >> Maybe a way to also make this less tied to the example implementation >> might be to have a second implementation example, and move the example >> implementation out of the plumtree module so we don’t ship dependencies >> inadvertently. >> That second example can be servlet-based if that helps with testing this >> out with Jetty. >> >> Cheers, >> >> Antoine >> >> >> > On Dec 11, 2022, at 9:22 PM, larry mccay <lmc...@apache.org> wrote: >> > >> > Tuweni Dev's - >> > >> > I am considering the possibility of a usecase for Plumtree and would >> like >> > to get the community's thoughts. >> > >> > I'd like multiple servers that have embedded Jetty servers to be able >> to be >> > aware of each other. I am considering using the gossip protocol support >> > provided by the plumtree library in Tuweni. Let's consider this a state >> > server usecase for now. >> > >> > I want to be able to register a new participant with any other >> participant >> > and that information be propagated across all participating instances. >> > Performance isn't necessarily critical due to the nature of the state >> being >> > replicated in this usecase and we are probably looking at a number in >> 10s >> > of participating nodes rather than anything in 100s or more. >> > >> > There may also be multiple replication types. For instance, instances >> > colocated in the same cluster may need to replicate state that should >> not >> > be replicated to instances in remote deployments while other data >> should be. >> > >> > I'm wondering a couple things: >> > >> > 1. Does this sound like a valid plumtree usecase? >> > 2. Could we get a dev tutorial page for plumtree that is similar to that >> > for net [1]? The getting started with plumtree page is currently empty >> [2]. >> > 3. I have looked at the gossip app sample but have quite got the >> > programming model teased out from the app implementation details. The >> > general programming mode description in #2 would be helpful. >> > 4. Would you recommend using vert.x (as is done in gossip) for this >> within >> > the Jetty based server or something more native to JEE and/or the Jetty >> > server? Jetty specific Handlers would be portable across Jetty servers, >> JEE >> > servlets or filters or the like would be portable across EE servers. >> > Perhaps, if vert.x is the recommendation it would be more appropriate >> as a >> > custom handler? >> > >> > I could help flesh out the getting started with plumtree page once I get >> > the ball rolling. That is assuming this usecase seems to sound >> reasonable. >> > >> > Thoughts? >> > >> > thanks! >> > >> > --larry >> > >> > 1. >> https://tuweni.apache.org/tutorials/networking/getting-started-with-net/ >> > 2. >> > >> https://tuweni.apache.org/tutorials/networking/getting-started-with-plumtree/ >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@tuweni.apache.org >> For additional commands, e-mail: dev-h...@tuweni.apache.org >> >>
