ZeroMq IRC Log

Tuesday June 1, 2010

[Time] Name	Message
[04:51] jugg	s.bind("tcp://localhost:15555"); fails with "no such device" However, s.bind("tcp://127.0.0.1:15555"); works fine, as does s.bind("tcp://lo:15555");
[04:51] jugg	whereas s.connect("tcp://localhost:15555"); and s.connect("tcp://127.0.0.1:15555"); both work fine, but s.connect("tcp://lo:15555"); fails with "Invalid argument".
[04:53] jugg	any combination of the successful bind/connect allow messages to flow just fine. (eg. bind - lo, connect - localhost)
[04:54] jugg	any idea why binding 'localhost' fails, and connecting 'lo' fails?
[07:38] sustrik	jugg: you can bind only to local NIC
[07:38] sustrik	"localhost" is a hostname not NIC name
[07:38] sustrik	use "lo"
[07:38] sustrik	"eth0" and alike
[07:39] sustrik	(on linux)
[07:53] jugg	sustrik: it must also accept local ip addresses. And since the zmq layer already can resolve hostnames, it would be a convience to have it do so here as well.
[07:55] sustrik	the problem is that there's no hint to distinguish between nic names and hostnames
[07:57] jugg	a simple if fail then try scheme could be used
[07:58] sustrik	yup, we've thought of that
[07:58] sustrik	presumably, resolve nic name first, hostname if it fails
[07:59] sustrik	obviously, it would mean that nic name can then overshadow a remote host
[07:59] jugg	yes, although I might think to have a hardcoded check for 'localhost' first.
[08:00] sustrik	it's up to OS to resolve names, 0mq should not mess with that imho
[08:02] jugg	certainly. I was saying that if the device is 'localhost' then just skip nic name lookup (being that localhost is quite the common case).
[08:03] sustrik	my point was that "localhost" is just a name a should thus be resolved by OS
[08:08] jugg	anyway, I assume that trying to connect to a nic name is nonsensical, which is why s.connect("tcp://lo:15555") fails? It certainly is an odd error message however "invalid arguement", now that I've played with it "invalid argument" is the error message for any bogus hostname. Not very helpful.
[08:18] jugg	all of this mucking around is because I got off track while trying to debug odd observed behavior with zmq resulting from the socket type and transport combination. eg pub/sub works fine with tcp:, but often fails with ipc:
[08:19] jugg	I haven't isolated it yet, so I can't give a useful bug report (if any).
[08:27] sustrik	interesting
[08:27] sustrik	the code is same for tcp and ipc
[08:27] sustrik	can you at least say what kind of error are you seeing?
[08:38] jugg	well, it could still yet be very much user error, but it appeared that subscriptions were not taking affect, and in several instances, I would get an error about the ipc: address having some problem (the exact error messages are out of my scrollback). Yet, those error message seemed to go away if I changed the socket type. And when using tcp: I've never seen either of those issues.
[08:49] sustrik	ok, i see
[08:49] sustrik	if it ever happens again please do report the problem
[09:39] jugg	hmm, I thought publications got into the bit bucket if the endpont doesn't exist. This is the case if the publisher is the one that binds the socket, but if it is the subscriber that binds the socket, then the publisher queues up all of its messages. Is this expected? And if so, why the change in behavior depending on which socket type binds/connects?
[09:53] sustrik	PUB/SUB messaging pattern is like a radio tranmission; if you are not listining to the broadcast you won't be able to catch up later on
[11:39] jugg	yes, so why is the publisher queuing up the messages?
[11:46] sustrik	jugg: the queueing is built in so that messages are not dropped all the time because of random traffic peaks
[11:46] sustrik	if you set HWM socket option on your publisher
[11:46] sustrik	you'll limit the size of the queue
[11:46] sustrik	once the max number of messages in the queue is reached, publisher will start dropping them
[11:47] jugg	yes, so why does this queuing only occur if the publisher connects? It doesn't occur if the publisher binds.
[11:48] sustrik	when you bind, there's no queue created at that moment
[11:48] sustrik	you don't know how many peers will connect in the future
[11:48] sustrik	and thus you cannot create appropriate number of queues
[11:49] sustrik	when you connect you need only one queue, so it's created immediately
[11:49] sustrik	the code can be changed so that 'connect' queue is created only when connecting to the peer succeeds
[11:50] sustrik	but i am not sure what advantage we would get from that
[11:50] jugg	consistency?
[11:50] sustrik	sure
[11:50] jugg	otherwise this needs documented.
[11:50] sustrik	well, the documentation is "messages can be dropped"
[11:50] sustrik	when exactly they are dropped is implemetation detail
[11:51] jugg	eh
[13:41] jugg	in a pub/sub configuration, it would appear that the only way to have multiple subscribers is if the pub socket is the one that binds the endpoint. In the case where a subscriber binds the endpoint, and the publisher connects, then other subscribers that connect do not receive publications. I'd expect that either all connecting subscribers receive the publications, or that it is not possible for other subscribers to successfully connect.
[13:43] sustrik	jugg: sorry, i've missed the point
[13:43] sustrik	can you say it in more simple way
[13:43] sustrik	?
[13:44] jugg	a subscriber binds an endpoint
[13:44] jugg	a publisher connects to the endpoint
[13:44] jugg	everything is happy
[13:44] jugg	more subscribers connect to the endpoint
[13:44] jugg	these subscribers do not receive publications
[13:45] sustrik	subscribers connect to the subscriber endpoint?
[13:45] jugg	yes
[13:45] sustrik	SUB socket is not compatible with another SUB socket
[13:45] sustrik	see zmq_socket(3)
[13:45] sustrik	SUB must speak to PUB and vice versa
[13:46] sustrik	what are you trying to do?
[13:46] jugg	which is why I'd expect the subsequent connects to fail.
[13:47] sustrik	yes, they should
[13:47] sustrik	but the connect is async
[13:47] sustrik	so the error should be delivered asynchronously
[13:47] sustrik	we need an error queue for that
[13:47] sustrik	TODO
[13:47] jugg	I see
[13:55] jugg	So if the subscriber binds the endpoint, it is essentially stating that this is a private subscription, multiple publishers can publish to this private subscription. Multiple subscribe message filters may be used by the subscriber if desired.
[13:56] jugg	If a publisher binds an endpoint, then many subscribers may connect to this endpoint. But a subscriber can only receive messages from a single publisher in this case.
[13:56] sustrik	i would say it's symmetric
[13:56] sustrik	consider you can connect the same socket multiple times
[13:56] sustrik	so, for example:
[13:56] sustrik	pub.bind (A)
[13:57] sustrik	sub1.connect (A)
[13:57] sustrik	sub2.connect (A)
[13:57] sustrik	is equivalent to:
[13:57] sustrik	sub1.bind (A)
[13:57] sustrik	sub2.bind (B)
[13:57] sustrik	pub.connect (A)
[13:57] sustrik	pub.connect (B)
[13:58] sustrik	resulting connection diagram looks the same in both cases
[14:00] jugg	clear enough, thanks.
[14:02] sustrik	you are welcome
[15:56] jugg	quoting http://www.zeromq.org/blog:road "we designed a minimalist wire protocol which can be described in a couple of paragraphs" Are those paragraphs available?
[18:58] cremes	is it expected behavior that zmq_term() has an assertion failure unless all sockets in the context are closed first?
[18:59] cremes	this is against 2.0.6 release
[19:44] mato	cremes: no, that would be a bug
[19:44] mato	cremes: however, that code has changed on master, so i suggest you re-test there
[19:44] cremes	all right... i'll test on master in a bit
[19:50] CIA-17	zeromq2: 03Martin Lucina 07master * r74a03df 10/ (AUTHORS foreign/xmlParser/xmlParser.cpp): Merge branch 'master' of github.com:sustrik/zeromq2 - http://bit.ly/9cipXX
[20:20] mato	cremes: since you asked about zmq_term()... I'm updating the docs for 2.0.7.
[20:20] mato	cremes: could you comment if the following is clear: ?
[20:20] mato	The zmq_term() function terminates the 0MQ context context.
[20:20] mato	If there are no longer any sockets open within context at the time zmq_term() is
[20:20] mato	called then context shall be shut down and all associated resources shall be
[20:20] cremes	ok; i'm compiling master now so i can see if i am still getting on behavior
[20:20] mato	released immediately.
[20:20] mato	Otherwise, the following applies:
[20:20] mato	Â· The zmq_term() function shall return immediately.
[20:20] mato	Â· Any blocking operations currently in progress on sockets open within context
[20:20] mato	shall return immediately with an error code of ETERM.
[20:20] mato	Â· With the exception of zmq_close(), any further operations on sockets open
[20:20] mato	within context shall fail with an error code of ETERM.
[20:20] mato	Â· The actual shutdown of context, and release of any associated resources,
[20:20] mato	shall be delayed until the last socket within it is closed with zmq_close().
[20:21] mato	cremes: thx, but read the above, since that's the behaviour on master
[20:21] mato	cremes: is my description clear enough?
[20:21] cremes	it makes perfect sense; it is very clear
[20:21] mato	great, thanks
[20:23] CIA-17	zeromq2: 03Martin Lucina 07master * r8ba1d3c 10/ (6 files): Documentation: zmq_term() and ETERM for 2.0.7 - http://bit.ly/cd4hIx
[20:23] CIA-17	zeromq2: 03Martin Lucina 07master * r9d00d30 10/ doc/zmq_init.txt : Documentation: zmq_init() API changes for 2.0.7 - http://bit.ly/bhbjsl
[20:28] versificateur	hello everyone!
[20:28] versificateur	i'm back to ask for some help aagin.. :)
[20:30] versificateur	i've some difficulties to run (compile) the c++ server code i wrote based on zmq blog examples
[20:31] versificateur	I got the following error: Package libzmq was not found in the pkg-config search path.
[20:32] cremes	versificateur: please pastie the whole error including the command you used
[20:34] versificateur	g++ `pkg-config --libs --cflags libzmq` -o server server.cpp Package libzmq was not found in the pkg-config search path. Perhaps you should add the directory containing `libzmq.pc' to the PKG_CONFIG_PATH environment variable
[20:35] versificateur	oops
[20:35] versificateur	g++ `pkg-config --libs --cflags libzmq` -o server server.cpp
[20:35] versificateur	Package libzmq was not found in the pkg-config search path.
[20:35] versificateur	Perhaps you should add the directory containing `libzmq.pc'
[20:35] versificateur	to the PKG_CONFIG_PATH environment variable
[20:37] versificateur	but I try locate and found the required at pkg-config
[20:37] versificateur	locate libzmq.pc
[20:41] sbeaulois	hi
[20:42] sbeaulois	i tried to compile zmq on RHEL but i have some errors when i tried ./configure configure: error: cannot link with -luuid, install uuid-dev
[20:42] sbeaulois	i cann't fin uuid-dev for RHEL
[20:43] mato	sbeaulois: I think it's called uuid-devel on RH
[20:43] sbeaulois	i have install uuid-devel but i have the same error
[20:46] mato	sbeaulois: which version of RHEL?
[20:47] sbeaulois	i use RHEL 5
[20:48] mato	don't know, sorry, I don't have that here... you need to install whichever package provides libuuid.a
[20:49] sbeaulois	fine
[20:49] versificateur	i resolve my problem by exporting the PKG_CONFIG_PATH
[20:49] versificateur	it compile fine
[20:50] versificateur	but when i run the binarie i have this error
[20:50] versificateur	./server: error while loading shared libraries: libzmq.so.0: cannot open shared object file: No such file or directory
[20:51] versificateur	it's similar to what an old issue i met with python bindings installation
[20:51] versificateur	is anyone experienced this before??
[20:52] mato	versificateur: you need to run ldconfig as root
[20:52] cremes	versificateur: your compile line is wrong; don't use "libzmq" just use "zmq"
[20:52] cremes	or what mato said :)
[20:53] versificateur	mato: before or after compile??
[20:54] mato	versificateur: only once, after doing make install for zmq
[20:54] versificateur	okay i'm trying
[20:56] versificateur	cremes: i don't think the zmq.cp exist
[20:56] mato	versificateur: no, it's libzmq.pc
[20:57] versificateur	so my compile line was right??
[21:00] mato	yes
[21:02] versificateur	i retried after ldconfig but still have the same issue
[21:03] mato	you did do a make install after building zeromq, yes?
[21:04] versificateur	after running ./configure make make install?
[21:04] versificateur	yes
[21:04] mato	don't know, then your system doesn't have /usr/local/lib in it's /etc/ld.so.conf or equivalent
[21:06] versificateur	yes i think so
[21:10] versificateur	i'll try by adding a zmq-64.conf with /usr/local/lib
[21:10] versificateur	to /etc/ld.so.conf.d
[21:10] versificateur	directory
[21:10] mato	yup, don't forget to rerun ldconfig when you make any changes
[21:17] versificateur	mato: thanks!!! it works
[21:18] versificateur	running netstat -l shoow me the zeromq port listening
[21:18] versificateur	now i can test my code...
[21:18] versificateur	thanks again :)
[21:22] mato	np
[21:25] sbeaulois	hi
[21:25] sbeaulois	i found solution of my problem
[21:26] sbeaulois	libuuid-devel is within of e2fsprogs package
[22:04] sbeaulois	ne help
[22:04] sbeaulois	need help
[22:04] sbeaulois	try to compil my java script but i have some error
[22:04] sbeaulois	java.lang.UnsatisfiedLinkError: /usr/local/lib/libjzmq.so.0.0.0: libzmq.so.0
[22:05] sbeaulois	not found
[22:05] sbeaulois	java.lang.UnsatisfiedLinkError: /usr/local/lib/libjzmq.so.0.0.0: libzmq.so.0: cannot open shared object file: No such file or directory