pieter,
i can’t figure out what you’re saying here. based on my several years
experience
with you, i have to conclude that i have somehow misspoken.
i have a distributed application. that is, there are a number of
discrete components
that (for this discussion) are distinct processes running on some number of
servers.
some are accessed thru RPC calls, others generate work that then processed by
some number of worker components.
in order for this to work, i clearly need to figure out how data will
flow
through this system. as i have understood the design methodology around zeromq,
this means figuring out the fixed points in the data flow and organising the
components around those fixed points. some of these allow for “scaling”
(as in increasing the size of a worker pool).
so i don’t understand
1) how can this sort of design be a “mistake”? how can you do anything without
(trying to) understand where the data needs to go?
2) many protocols (which i guess you mean things defined by RFCs) don’t scale;
they simply detail teh bi-lateral contract between (roughly) user and supplier
of a service
(like NTP). i know some address this directly (like the Gossip protocol), but
surely you don’t mean just those?
andrew
> On Aug 24, 2016, at 11:06 AM, Pieter Hintjens <[email protected]> wrote:
>
> FWIW I have come to believe that trying to design or even understand
> the overall flows of data is a mistake, at least when you want to
> scale.
>
> What does scale is to speak of protocols and implementations. I know
> this isn't a happy answer yet it's a proven one (RFCs, Internet).
>
> _______________________________________________
> zeromq-dev mailing list
> [email protected]
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
