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

Reply via email to