On Mon, Feb 7, 2011 at 9:28 PM, Gaspard Bucher <gasp...@teti.ch> wrote:
> I have read the guide at least twice but there is no example of many REQ > sockets connected to a single REP socket... Since this is the pattern where > I get lost messages I am starting to doubt that I have understood things > properly. OK, I wasn't sure where you were but this is clear. You can connect many REQ to one REP, it's the basic hello world example; the REP gets one request at a time, fair queued from each REQ. Each REQ sends a request and waits for an answer. At a glance perhaps you're trying to connect and bind to the same address (though your code appears to be connecting both in server and client?). You cannot bind to a DNS name, you have to bind to a local interface, and I'd recommend "tcp://*:port" as the simplest (binds to all interfaces and is portable). You can easily regexp the DNS name into a bindable interface name. Cheers, -- Pieter Hintjens iMatix > But, using the same code with the service browser (mDNS), things go wrong: > both server and client see the server announcement: the server manages to > connect, send and receive an answer. The client can connect, send, but the > message is never received on the other end (so it hangs waiting for an > answer). > Both the server and client run an mDNS browser and they execute the exact > same code (so they should print the same debugging information): > SERVER: > # Browser found "Saturn" service on the network > ADD Saturn > # connect > req:connect tcp://gaspard.local.:3720 > # send request > req tcp://gaspard.local.:3720 /rk/info > # this is from the service itself (in same process) > recv() > # answer received, all OK > req done 17620 > CLIENT: > # Browser found "Saturn" service on the network > ADD Saturn > # connect > req:connect tcp://gaspard.local.:3720 > # send request > req tcp://gaspard.local.:3720 /rk/info <--- Get server info > # ... hangs ... > All method calls are checked for return values and recv() prints "recv()". > So how is it that the "send" goes fine, but the remote never sees the > message ? > Is there something I can look at in gdb, some internal queue that would give > me a hint on what happens to this lost message ? > Any help much welcomed... > Gaspard > On Mon, Feb 7, 2011 at 7:16 PM, Pieter Hintjens <p...@imatix.com> wrote: >> >> Hi Gaspard, >> >> Your best way to learn the 0MQ socket types is probably to read the >> Guide at http://zguide.zeromq.org, and follow the examples. It will >> take you a day or so depending how deep you go. >> >> It should be quite clear then how REQ/REP work. >> >> - >> Pieter Hintjens >> iMatix >> >> On Mon, Feb 7, 2011 at 6:55 PM, Gaspard Bucher <gasp...@teti.ch> wrote: >> > Hi there ! >> > I am not sure if what I want to do is really how REQ/REP sockets should >> > be >> > used or what is the proper way to handle this: >> > I announce a service with an IP and port using mDNS. When a client sees >> > the >> > service, it needs to connect and ask for some other ports (or update >> > information or do other stuff). >> > This means that I am using REQ/REP sockets like traditional >> > listen/accept >> > based sockets (on the REP side) and it does not seem to work. >> > Do I have to use another library if I need multiple REQ sockets >> > connected to >> > a single REP ? >> > Gaspard >> > _______________________________________________ >> > zeromq-dev mailing list >> > zeromq-dev@lists.zeromq.org >> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev >> > >> > >> _______________________________________________ >> zeromq-dev mailing list >> zeromq-dev@lists.zeromq.org >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > _______________________________________________ > zeromq-dev mailing list > zeromq-dev@lists.zeromq.org > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > _______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev