[zeromq-dev] C examples do not work on my PC, either with ipc or tcp, except ipc with server & client executed in the same console

[Laurent Alebarde]

If I use tcp://127.0.0.1:5555 instead of tcp://localhost:5555, it works.
I don't understand since in my /etc/hosts, localhost is declared :

# grep localhost /etc/hosts
127.0.0.1    JANUS localhost
#::1        localhost

But it is not annoying, so for me the socket issue is closed. Remains 
the ipc transport which still does not work on my PC (except when both 
server & client are runned in the same console).


Le 26/06/2013 16:48, Laurent Alebarde a écrit :
> Last message with Python was a test with ipc. Now with tcp, I get 
> something that may be interesting, but myself, I don't know what to do 
> with it :
>
> $ python flserver1.py "tcp://localhost:5555" &
> [1] 18561
> $ Traceback (most recent call last):
>   File "flserver1.py", line 18, in <module>
>     server.bind(endpoint)
>   File "socket.pyx", line 432, in zmq.core.socket.Socket.bind 
> (zmq/core/socket.c:4022)
>   File "checkrc.pxd", line 21, in zmq.core.checkrc._check_rc 
> (zmq/core/socket.c:5838)
> zmq.error.ZMQError: No such device
>
>
>
> Le 26/06/2013 16:40, Laurent Alebarde a écrit :
>> I have the same results with the Python examples. So the problem does 
>> not originate in my C/C++ build chain :
>> OK if client & server are in the same console, fails in two different 
>> consoles.
>>
>>
>> Le 26/06/2013 15:06, Laurent Alebarde a écrit :
>>> Hi list,
>>>
>>> I cannot manage to have my code working. It seems that I am sticked 
>>> in zmq_poll. Even in an infinite while, a printf and a 100 ms 
>>> time-out, the printf executes only once, so I conclude that in my 
>>> code, zmq_poll blocks internally.
>>>
>>> So I have tried the examples - precisely flclient1 along with 
>>> flserver1 - starting the server first of course. I have tried with 
>>> ipc and tcp and it does not work, probably for the same reasons, 
>>> except with ipc in the same console :
>>>
>>> console server :
>>> $ ./flserver1 ipc://test.ipc &
>>> [1] 17822
>>> $ I: echo service is ready at ipc://test.ipc
>>>
>>> console client :
>>> $ ./flclient1 ipc://test.ipc
>>> I: trying echo service at ipc://test.ipc...
>>> W: no response from ipc://test.ipc, retrying...
>>> I: trying echo service at ipc://test.ipc...
>>> W: no response from ipc://test.ipc, retrying...
>>> I: trying echo service at ipc://test.ipc...
>>> W: no response from ipc://test.ipc, retrying...
>>>
>>>
>>> In the same console, it works :
>>> $ ./flserver1 ipc://test.ipc &
>>> [2] 17800
>>> [1]   Fini                    ./flserver1 ipc://test.ipc
>>> $ I: echo service is ready at ipc://test.ipc
>>>
>>> $ ../../flclient1/Release/flclient1 ipc://test.ipcI: trying echo 
>>> service at ipc://test.ipc...
>>> Service is running OK
>>>
>>> With tcp, it does not work either in the same console or not :
>>> $ ./flserver1 tcp://localhost:5555&
>>> [1] 17841
>>> $ I: echo service is ready at tcp://localhost:5555
>>>
>>> $ ../../flclient1/Release/flclient1 tcp://localhost:5555
>>> I: trying echo service at tcp://localhost:5555...
>>> W: no response from tcp://localhost:5555, retrying...
>>> I: trying echo service at tcp://localhost:5555...
>>> W: no response from tcp://localhost:5555, retrying...
>>> I: trying echo service at tcp://localhost:5555...
>>> W: no response from tcp://localhost:5555, retrying...
>>>
>>> My iptables authorises inputs on localhost  (if I am not wrong):
>>>
>>> # iptables -L -n
>>> Chain INPUT (policy DROP)
>>> target     prot opt source               destination
>>> ACCEPT     udp  --  127.0.0.0/24 0.0.0.0/0            udp dpt:80
>>> ACCEPT     tcp  --  127.0.0.0/24 0.0.0.0/0            tcp dpt:80
>>> ACCEPT     all  --  0.0.0.0/0 0.0.0.0/0            state 
>>> RELATED,ESTABLISHED
>>> REJECT     tcp  --  0.0.0.0/0 0.0.0.0/0            reject-with tcp-reset
>>> REJECT     udp  --  0.0.0.0/0 0.0.0.0/0            reject-with 
>>> icmp-port-unreachable
>>> ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
>>> ACCEPT     icmp --  0.0.0.0/0 0.0.0.0/0            icmptype 0
>>> ACCEPT     udp  --  192.168.0.0/24 0.0.0.0/0            udp dpt:631
>>> ACCEPT     tcp  --  192.168.0.0/24 0.0.0.0/0            tcp dpt:631
>>>
>>> Chain FORWARD (policy DROP)
>>> target     prot opt source               destination
>>> ACCEPT     all  --  192.168.99.0/24     !192.168.0.0/24
>>> ACCEPT     all  --  0.0.0.0/0 0.0.0.0/0            state 
>>> RELATED,ESTABLISHED
>>>
>>> Chain OUTPUT (policy ACCEPT)
>>> target     prot opt source               destination
>>>
>>>
>>> Here are for information the compile command (from Eclipse) :
>>> Command : g++-4.7.3
>>> Options :  -O3 -Wall -c -fmessage-length=0  -std=c++11 -march=corei7 
>>> -mtune=corei7
>>>
>>> and for the linker :
>>> Command : g++-4.7.3
>>> Options :  -l czmq
>>>
>>>
>>> Any idea please ?
>>>
>>>
>>> _______________________________________________
>>> 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/20130626/af06af95/attachment.htm>