[nanomsg] Re: Design of a distributed computing framework
- From: Alex Elsayed <eternaleye@xxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Wed, 25 Feb 2015 02:05:39 -0800
Stefano wrote:
> On 25 Feb 2015 06:41, "Alex Elsayed"
> <eternaleye@xxxxxxxxx> wrote:
>>
>> Stefano wrote:
<snip>
>> > The problem I don't know how to solve is that only master is
>> > guaranteed to have a public IP, client and worker might be using an
>> > ISP that do not offer a directly reachable public IP.
>> > This means that they only connections that are guaranteed to work are
>> > connect() toward the master IP.
>> > I am confident that there is a solution to this, but I'm not an expert
>> > in the field so I don't know how this problem is usually approached.
>>
>> The hat-trick is that which side is REQ and which side is REP is
> independent
>> of which side calls bind() and which side calls connect().
>>
>> You can certainly have the master server bind() one REP (the job
> submission
>> endpoint) and one REQ (the work dispatching endpoint). Clients would
>> connect() to the former, and workers would connect() to the latter.
>
> Yes, that's exactly the way I have done it: a RAW REQ server and a RAW REP
> server joined by device(), no need to manually handle end-to-end info at
> all.
>
> Thanks for confirming this symmetry is by design, I was unsure about that.
One further upside of this is that you can have multiple instances of the
device, and make the clients/workers connect to _all_ of them. Thus, even if
one goes down, the topology continues functioning.
<snip>
Other related posts:
