[zeromq-dev] Using ZMQ_FD with select
schmurfy at gmail.com
Tue Feb 21 18:02:12 CET 2012
I mainly use ROUTER/DEALER for a simple reason: asynchronous communication,
I consider REQ/REP to be fine for really simple client otherwise I stay
away from them (but you can use a REQ in front of a ROUTER which is the old
Working on the em-zeromq ruby library we have already found some really
strange behavior linked to the way the returned descriptor worked but once
you got them all it seems pretty reliable.
On 19 February 2012 16:15, Yi Ding <yi.s.ding at gmail.com> wrote:
> On Sun, Feb 19, 2012 at 4:02 AM, Schmurfy <schmurfy at gmail.com> wrote:
> > Now I really feel stupid xD
> > Thanks for pointing this out, not really intuitive.
> > I am back to square one since it does not explain my problem then xD
> > But I am curious what was your problem with REQ/REP if not this one
> > I also have problems with REQ/REP where the other sockets type works as
> > intended.
> > I just can't pinpoint what exactly is wrong and where.
> My problems with REQ/REP mainly came from the fact that it enforces
> this strict ordering of request, reply, request, reply. So it's
> really meant for synchronous communication, for both the client and
> the server. Trying to get it to work with asynchronous communication
> meant that I would have to create my own queues and monitor those, and
> make sure not to miss any incoming messages on the select, make sure I
> was resetting the edge triggering properly (which is doubly hard
> because calling recv too many times on a REQ or REP socket will
> trigger EFSM).
> Ultimately it turned into too much work. I've found a pair of
> PUSH/PULL sockets works well if the endpoints are all known in
> advance. Other people have suggested ROUTER/DEALER, but I haven't
> tried that yet. Also, if the endpoints aren't known in advance,
> PUB/SUB can work, although endpoint discovery is pretty tricky right
> now because there's no way to get the IP address off an inbound
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the zeromq-dev