[zeromq-dev] question about HWM

[Diffuser78]

Hi,

I had a very simply client and server processes. The server pushes say ~1
GB of data to client. When I used REQ/REP, everything was fine. When I
tried the same program with DEALER/ROUTER, I got seg faults. Can you just
replace REP/REQ with DEALER/ROUTER or are there semantics that are related
to DEALER/ROUTER that needs to be followed.

I am still reading zguide but since its quite exhaustive, I am yet to reach
to the messaging patterns.

Thanks.

On Thu, Jun 21, 2012 at 5:48 PM, Chuck Remes <lists at chuckremes.com> wrote:

> On Jun 21, 2012, at 6:23 PM, Diffuser78 wrote:
>
> > Thanks, Chuck, for your views and insight on this. I have a fairly
> newbie question about the messaging pattern:
> >
> > In my scenario, App1 (server) pushes say ~10 MB of data to App2 (client)
> periodically. In this case, can I make my App1 as REQ and App2 as REP ? In
> this communications, App1 is the initiating entity and also the one that
> sends payload and App2 is the receiving entity. Is there any rule of thumb
> or recommended practice about who should be REQ versus who should be REP ?
> >
> > Many thanks.
>
> What you describe above is a pretty classic example for using REQ/REP.
> Generally, I recommend that people use DEALER/ROUTER (formerly named
> XREQ/XREP) for communications so that you can send multiple requests and
> multiple replies without being tied to the req/rep/req/rep pattern enforced
> by the REQ/REP sockets.
>
> Anyway, the rule of thumb is that the entity creating the work or the
> request should be the REQ or DEALER socket. The entity (or entities)
> handling the work and generating the reply should be the REP (or ROUTER)
> socket. So, you have it exactly right. It really is as simple as it looks.
>
> cr
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20120622/54e70296/attachment.htm>