[zeromq-dev] Advice on server sync architecture

Michel Pelletier pelletier.michel at gmail.com
Tue Aug 12 15:39:17 CEST 2014


Check out the 0mq guide.  It contains a number of useful patterns.  It
sounds like what you want is called the clone pattern.

-Michel

On Tue, Aug 12, 2014 at 1:45 AM, Gerry Weaver <gerryw at compvia.com> wrote:
> Hello All,
>
>
>
> Well… I guess it’s time to call it a night. The information provided about
> the requirements was pretty much nonexistent. These servers synchronize
> configuration and state information between each other. The idea is that a
> client can connect to any server in the cluster and get the current state
> and configuration of all servers in the cluster. High performance is not
> really a requirement in this case. The main goal was to avoid the need for a
> central management server. It looks like PUB/SUB might work, but I would
> need to deal with disconnection detection and synchronization state.
> Currently a server can publish a sync status request to all other servers
> and receive an in memory and on disk state version from each. For example,
> this occurs when a client connects to a particular server. It looks like I
> may have to combine several zeromq concepts/patterns to achieve this.
>
>
>
> Thanks,
>
> -G
>
>
>
>
>
> From: zeromq-dev-bounces at lists.zeromq.org
> [mailto:zeromq-dev-bounces at lists.zeromq.org] On Behalf Of Gerry Weaver
> Sent: Tuesday, August 12, 2014 2:52 AM
> To: zeromq-dev at lists.zeromq.org
> Subject: [zeromq-dev] Advice on server sync architecture
>
>
>
> Hello All,
>
>
>
> I’ve got some existing server code that I’m thinking about replacing with
> zeromq. The best way to describe it in zeromq terms would be that each
> server has a PUB socket that every other server connects to via a SUB
> socket. When an event occurs on any server, it is published to the rest. The
> current code just uses TCP sockets and SSL. The PUB/SUB pattern would be the
> most straight forward change to the existing code, but I’m wondering if
> there is a better way to accomplish the same thing. Any alternative design
> recommendations would be much appreciated.
>
>
>
> Thanks,
>
> -G
>
>
>
>
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>



More information about the zeromq-dev mailing list