Hi James,
thanks for the answer. You're right, Python bindings for zyre are
automatically generated stubs for calling C directly. Those can be
integrated to async python but one must do it manually.
The main reason I wrote about zyre is that the protocol is already defined
and can be learned
On Tue, Jun 26, 2018 at 1:42 PM Michal Vyskocil
wrote:
> Zyre, it supports discovery and reliable group messaging without a broker.
> https://github.com/zeromq/zyre/blob/master/README.md#scope-and-goals
>
> Malamute,the zeromq broker. It provides pub/sub, request/reply and service
>
partial subject of the caches they are interested in
>>>> + Consumers parse the incoming json's, decide best cache and connect to
>>>> it directly (bypassing the proxy).
>>>>
>>>> This system works between the DC and cloud (AWS). I also have a sys
gt;>> prefix partial subject of the caches they are interested in
>>> + Consumers parse the incoming json's, decide best cache and connect to
>>> it directly (bypassing the proxy).
>>>
>>> This system works between the DC and cloud (AWS). I also have a syste
org>>
On Behalf Of Bill Torpey
Sent: 23 June 2018 21:29
To: ZeroMQ development list
mailto:zeromq-dev@lists.zeromq.org>>
Subject: Re: [zeromq-dev] zmq architecture/protocol planning
Hi James:
I’m doing something similar on the service discovery end, but it’s a work in
progress, so t
UB have to filter on the SUB
>> side) and you need a mcast capable network.
>>
>> James Harvey
>>
>>
>> From: zeromq-dev On Behalf Of Bill
>> Torpey
>> Sent: 23 June 2018 21:29
>> To: ZeroMQ development list
>> Subject: Re: [zeromq-dev]
mailto:zeromq-dev@lists.zeromq.org>>
Subject: Re: [zeromq-dev] zmq architecture/protocol planning
Hi James:
I’m doing something similar on the service discovery end, but it’s a work in
progress, so take this with the appropriate amount of salt ;-)
It seems a good idea to minimize state as much
info. This is nice as there is no single point of failure but you
> have more discovery traffic (as mcast PUB/SUB have to filter on the SUB
> side) and you need a mcast capable network.
>
> James Harvey
>
>
> From: zeromq-dev On Behalf Of Bill
> Torpey
> Sent: 23 June 20
Thanks for the detailed response, Bill. You've raised many interesting
approaches/ideas in here for me to look into - I appreciate it.
On Sat, Jun 23, 2018 at 1:30 PM Bill Torpey wrote:
> Hi James:
>
> I’m doing something similar on the service discovery end, but it’s a work
> in progress, so
have more
discovery traffic (as mcast PUB/SUB have to filter on the SUB side) and you
need a mcast capable network.
James Harvey
From: zeromq-dev On Behalf Of Bill Torpey
Sent: 23 June 2018 21:29
To: ZeroMQ development list
Subject: Re: [zeromq-dev] zmq architecture/protocol planning
Hi
Hi James:
I’m doing something similar on the service discovery end, but it’s a work in
progress, so take this with the appropriate amount of salt ;-)
It seems a good idea to minimize state as much as possible, especially
distributed state, so I have so far avoided the central “registrar”,
Looking for a little guidance/advice on ZMQ implementation.
The following demonstrates the simplistic architecture that I'm
considering. It doesn't take into consideration redundancy, load balancing
at all levels (yet). The general flow of request/response traffic would be:
-> HTTP request from
12 matches
Mail list logo
