ZeroMq IRC Log

Friday April 29, 2011

[Time] Name	Message
[00:00] mikko	the message is arbitrary binary blob, a string or a number or anything
[00:00] mikko	but you are always guaranteed to receive the whole message on the other side
[00:00] mikko	the message can be instruction to call a function
[00:00] mikko	or execute a binary
[00:00] mikko	but this is something you need to implement
[00:01] mikko	think about for example this chatroom
[00:01] mikko	we send messages all the time
[00:01] mikko	you might even say that we publish messages in topic #zeromq
[00:01] mikko	another channel is would be another topic
[00:01] mikko	(using pub-sub terms)
[00:02] Bartzy	instruction to execute a binary = string that I need to check for and do something with it, right ?
[00:02] mikko	yes
[00:02] Bartzy	yes I understand the pub-sub thingie
[00:02] Bartzy	OK.. and how can I send a file using zeromq ?
[00:02] Bartzy	is that recommended ?
[00:03] Bartzy	or there are better ways to store a file and send it (via NFS)?
[00:03] mikko	send it where?
[00:05] Bartzy	I have a web server, a client sends a request to do an effect on a URL
[00:05] Guthur	Bartzy, working through at least some of the Guide examples can be could to get things to 'click'
[00:06] Guthur	could/good
[00:07] Bartzy	PHP downloads that image from the URL, then it needs to store it some where the image-processing server(s) can access it. It then should send a message or a 'job' for one of the image-processing servers to do a specific effect on that image, and save the new image in a place where the web server can access (for the user to fetch)
[00:08] Bartzy	So storing the original image and the result image - is that best done via NFS , or using ZMQ to get the original image to the image-processing server(s), and then the result image from the image-processing servers to the web server through ZMQ as well...
[00:10] DanielFriesen	sigh I wish there was a nice api like ZMQ that also supported udp messages that could just be dropped, or would let you know what connections it still has alive...
[01:43] josh	hi
[01:44] josh	does anyone know how to do a rate limit on a pull socket
[05:21] CIA-75	libzmq: 03Martin Sustrik 07master * rb2eb84f 10/ (4 files): Substantial simplification of uuid_t ...
[05:30] CIA-75	libzmq: 03Martin Sustrik 07master * r96213d5 10/ src/tcp_connecter.cpp : WSAENETUNREACH is a valid networking error ...
[10:35] travlr	mikko: ping
[10:35] mikko	yes?
[10:35] travlr	hey, i'm just now working with the irc log you gave me.. what time zone are you in?
[10:36] mikko	BST at the moment
[10:36] travlr	the log is in bst then?
[10:36] mikko	well, it is during summer
[10:37] travlr	the dates are from march 2010 to i think it was november 2010
[10:38] mikko	London will stay on BST until Sunday, October 30, 2011 at 2:00 AM
[10:38] mikko	when clocks are moved to Sunday, October 30, 2011 at 01:00:00 GMT
[10:38] travlr	ok, i think i only need july anyway, so thank you.
[10:39] mikko	no problem
[14:16] ianbarber	pieterh: here?
[14:16] pieterh	ianbarber: aye
[14:16] ianbarber	jujst
[14:17] ianbarber	argh, typing fail :)
[14:17] pieterh	:)
[14:17] ianbarber	just looking at the titanic pattern
[14:17] ianbarber	titanic.c, titanic_request
[14:17] ianbarber	creates a zmsg reply, but doesn't seem to send it:
[14:17] ianbarber	â//ââNowâsendâUUIDâbackâtoâclient
[14:17] ianbarber	ââââââââreplyâ=âzmsg_newâ();
[14:17] ianbarber	ââââââââzmsg_addstrâ(reply,â"200");
[14:17] ianbarber	ââââââââzmsg_addstrâ(reply,âuuid);
[14:17] ianbarber	ââââââââfreeâ(uuid);
[14:17] pieterh	let me check...
[14:18] pieterh	hmm, indeed...
[14:19] pieterh	I must have chopped that out by mistake at some stage, thanks
[14:21] ianbarber	cool - i was about to go trawling through zmsg for some magic i was not previously aware of :)
[14:21] pieterh	I ported all the examples to libzapi/czmq and presumably didn't retest everything properly
[14:21] pieterh	I'll fix this right now
[14:21] ianbarber	yeah, easy to do.
[14:22] ianbarber	when you have a tick as well, i sent a pull req for the MDP examples https://github.com/imatix/zguide/pull/53
[14:22] ianbarber	(in php)
[14:22] pieterh	nice!
[14:22] pieterh	the guide is like a kind of complex game, and as you catch up I have to go build new levels...
[14:23] ianbarber	hehe
[14:23] pieterh	while sustrik busily keeps shifting the foundations so the levels don't remain stable
[14:24] ianbarber	got to keep things interesting! :)
[14:24] pieterh	yeah
[14:24] pieterh	strangely the old code didn't send a reply back either
[14:24] pieterh	so this may in fact be wrong, I need to re-read how titanic works in detail
[14:25] guido_g	hehehe
[14:25] guido_g	sorry
[14:26] ianbarber	you know you've got a good spec when it's a better source than the reference implementation though.
[14:27] ianbarber	too many are done the other way around
[14:27] pieterh	yeah, that's true
[14:33] pieterh	ianbarber: ah, ok, the code was correct
[14:33] pieterh	it's my fault for being too clever with the mdwrk API
[14:34] ianbarber	ah, i see it's on the next loop
[14:34] ianbarber	yep, that makes sense, just missed it before
[14:34] pieterh	I wanted to get a single method for 'send-wait-recv' instead of two
[14:36] pieterh	I'll comment the code a little better, and maybe change the API later on
[14:40] ianbarber	i think a comment should do it, just to avoid confusion
[14:48] pieterh	yup, done
[14:48] pieterh	publishing a new version now
[15:02] sustrik	pieterh: hi
[15:02] pieterh	sustrik: hey! how was Moscow?
[15:02] sustrik	great
[15:02] sustrik	the meetup was in pub
[15:02] pieterh	well, no kidding?
[15:02] sustrik	so more a drinking event
[15:03] mato	when was a meetup not a drinking event? :)
[15:03] sustrik	true
[15:03] sustrik	anyway, want to have a look at issue 191 now?
[15:03] sustrik	the backport thing
[15:03] pieterh	sustrik: did you find anything?
[15:03] sustrik	haven't looked so far
[15:04] sustrik	afaiu the problem you've seen doesn't happen anymore
[15:04] sustrik	so what's left are the problems with backported version, right?
[15:04] pieterh	well, I found 2-3 different issues
[15:04] sustrik	alllin issue 191
[15:04] pieterh	sustrik: I made a gist/repo with all the details
[15:04] sustrik	right?
[15:05] pieterh	yes, 191
[15:05] sustrik	all of them in 2.1
[15:05] pieterh	afaics 2-1 and 3-0 die with similar problems though in different places
[15:05] pieterh	3-0 definitely is not stable after the patch
[15:05] sustrik	do we have a test case?
[15:05] pieterh	yes yes and yes
[15:05] sustrik	great
[15:05] pieterh	could you please grab that gist and ready it?
[15:05] pieterh	I spent quite some time documenting this, making test cases
[15:06] pieterh	*read it
[15:06] sustrik	yup
[15:06] pieterh	I'm 80% sure if you fix the problem in 3-0 we'll be able to fix 2-1 similarly
[15:06] pieterh	for some reason 3-0 is easier to type than 3.0 today...
[15:08] sustrik	:)
[15:08] sustrik	ok, let me try to reproduce
[15:08] sustrik	mato: btw, have you heard of andrew hume?
[15:08] sustrik	he've offered to help with man pages
[15:08] mato	sustrik: what about him?
[15:08] th	pieterh: i have the feeling zmq_msg_data() does not return the pointer to the mp-part of the last zmq_recv, but the data-pointer of a msg that would be received by later calls to zmq_recv (which are already waiting)
[15:08] mato	sustrik: oh, yes, i heard from him
[15:08] sustrik	goodo
[15:09] mato	sustrik: exchanged a couple of emails but nothing concrete has come of it as yet
[15:09] pieterh	th: that's unpossible afaik
[15:09] th	pieterh: i converted the test case to pure c now. and it happens even with only a single call to ./stress
[15:10] pieterh	ok, push your test case somewhere, I'll give it a go
[15:13] th	pieterh: i could not make it much smaller, yet. it's only translated from c++: http://thzn.de/0mq-mp-mix-pure-c/
[15:14] th	pieterh: just added the output.txt
[15:15] pieterh	sustrik: just tried again with master+patch, both pub and sub die
[15:16] sustrik	ok
[15:16] pieterh	there is a memory corruption somewhere, because sub dies in weird ways that change when I try to add printfs
[15:17] sustrik	compiling it
[15:18] pieterh	sustrik: I'm getting a random EINVAL on rc = zmq_getsockopt (s, ZMQ_RCVMORE, &more, &moresz);
[15:18] pieterh	in the sub test
[15:19] pieterh	but I think it's caused by some memory corruption issues
[15:21] sustrik	looks like
[15:21] pieterh	sustrik: do you always run ldconfig after installing a new libzmq version?
[15:21] sustrik	no idea
[15:21] sustrik	mato?
[15:22] pieterh	anyhow, that changes nothing... the subscriber dies with EINVAL on a valid getsockopt, the pub segfaults in array.hpp as documented
[15:22] pieterh	code is hard :)
[15:25] sustrik	ok, reproduced
[15:25] pieterh	excellent!
[15:26] sustrik	digging in
[15:26] pieterh	I think there is a problem in the new zmq_recv() method
[15:27] sustrik	doesn't happen when you use zmq_recvmsg?
[15:27] pieterh	the bogus result on getsockopt only hits with zmq_recv, not zmq_recvmsg
[15:27] pieterh	I have two otherwise identical subs, one works, one fails
[15:27] sustrik	i se
[15:27] sustrik	see
[15:30] pieterh	sustrik: it was a bug in your C testcase... uninitialized 'size_t moresz'
[15:31] sustrik	aha
[15:31] pieterh	so, subscriber is stable, publisher does crash
[15:31] mato	sustrik: what's up?
[15:32] mato	sustrik: sorry, am distracted, not paying attention here ...
[15:32] pieterh	mato: I was asking if one needs to run ldconfig when installing new version of libzmq
[15:32] mato	pieterh: you should always run ldconfig as root after doing make install
[15:32] pieterh	ah, good to know
[15:32] sustrik	hm, i never did that
[15:32] mato	pieterh: in some cases it's redundant but it won't hurt
[15:32] sustrik	even if the new version just overwrites the old one?
[15:33] sustrik	as in recompiling
[15:33] mato	sustrik: no, then you don't need to do that
[15:33] sustrik	ok
[15:33] mato	sustrik: but explaining to users that only run this if the ABI version is different is not worth the trouble
[15:33] mato	given that running it won't hurt anything
[15:33] pieterh	but between 2.1 and 3.0 for instance it's needed...
[15:34] mato	yes, because the soname changes
[15:34] Guthur	sustrik, would you have any issues with changing the clrzmq2 bindings license?
[15:35] sustrik	Guthur: it's your project
[15:35] sustrik	you choose the license
[15:36] Guthur	sustrik, well it contains a little code from the original bindng
[15:36] Guthur	binding*
[15:36] sustrik	ah
[15:36] sustrik	sure, go on
[15:36] sustrik	what license do you want to use?
[15:36] Guthur	i still need to contact Jeffery
[15:36] Guthur	may LGPL, or MIT
[15:37] Guthur	I don't really care too much, just that GPL turns some people off
[15:37] sustrik	it's GPL ???
[15:37] Guthur	it would appear so
[15:37] sustrik	how the hell that happened?
[15:37] Guthur	I only noticed this recently
[15:37] Guthur	oh doh
[15:37] Guthur	wait I'm blind
[15:37] Guthur	sorry false alarm
[15:38] Guthur	it's LGPL
[15:38] sustrik	:)
[15:38] pieterh	lol
[15:38] pieterh	LICENSE PANIC!!!
[15:38] pieterh	Guthur: good to hear there's no problem after all
[15:38] Guthur	hehe
[15:39] Guthur	I think it's because the Lesser comes before GNU General Public License
[15:39] Guthur	and I started reading at GNU
[15:40] Guthur	the real lesson here is that I should read license agreements alot more carefully
[15:40] sustrik	actually, the wording is incorrect
[15:40] sustrik	it should be "GNU Lesser GPL"
[15:40] sustrik	we've fixed that in the core
[15:41] sustrik	but obviously it remained in clrzmq
[15:41] sustrik	feel free to fix ti
[15:41] sustrik	it
[15:50] Guthur	ah ok, cool
[15:51] Guthur	I did think it weird to have the GNU after Lesser
[16:05] sustrik	pieterh: can you check with this patch instead of the old one:
[16:05] sustrik	https://gist.github.com/948531
[16:09] mikko	sustrik: build failure
[16:10] sustrik	let me see
[16:10] mikko	http://build.zero.mq/view/libzmq/
[16:11] mikko	uuid related changes
[16:11] sustrik	ah, uuid + pgm interaction
[16:11] sustrik	i haven't tested that
[16:11] sustrik	me bad
[16:11] mikko	that's fine
[16:12] sustrik	wait a sec
[16:12] mikko	at least you get post-commit reviews :)
[16:12] sustrik	heh
[16:12] mikko	i'm unable to build debian packages though
[16:12] mikko	not sure how to use the debian/
[16:12] mikko	mato: there?
[16:12] mato	mikko: ja
[16:13] mikko	how do you build debian packages?
[16:13] mato	mikko: the debian/ stuff in git is kinda outdated
[16:13] mikko	i can add debian packages to daily builds (x86 and amd64) if it's somewhat easy
[16:13] mikko	http://snapshot.zero.mq/ already contains rpms
[16:14] mato	mikko: not right now ... the debian/ stuff currently doesn't deal with building snapshot packages
[16:14] mikko	can debian/ live under builds/?
[16:14] mikko	or does that complicate things?
[16:15] mato	mikko: that complicates things
[16:15] mato	currently debian/ can either go away altogether or needs to be updated to build snapshot packages
[16:16] mato	but i'm not sure of the value of those
[16:16] mikko	people can test more easily
[16:16] mikko	im planning to do yum repo for rpms later on
[16:16] mato	can we discuss this another time? /me is deep into trying to figure out how to get a chrome extension to talk to something else via zmq
[16:16] mato	(don't ask why)
[16:17] mikko	hehe, sure
[16:18] sustrik	oh my, chrome extension? you should have been on that webdev conf in moscow instead of me
[16:20] mato	i need to get a running instance of chrome to talk to a running instance of lynx (yes, the webbrowser from 1995) and vice versa
[16:20] mikko	ahmmmm
[16:20] mikko	i'm not gonna ask
[16:20] mato	:-)
[16:28] staylor	just throwing it out there, but have you guys ever considered cmake? I've used it to build rpms/debs and saves the hassle of maintaining spec/debian configurations.
[16:33] sustrik	it've been discussed several times
[16:34] sustrik	mikko: i have a patch, but i need steven to approve
[16:34] sustrik	it
[16:34] sustrik	i guess i just post it to the ML and won't commit it straight away
[17:03] pieterh	re
[17:04] pieterh	sustrik: do you want me to test that patch then?
[17:04] sustrik	yes
[17:04] pieterh	ok
[17:04] sustrik	i've tried pub.c and sub.c
[17:04] sustrik	and it seems to fixed the issue
[17:04] sustrik	however, confirming it would be good
[17:08] pieterh	sustrik: it complains that the patch is corrupt at the last line
[17:08] pieterh	how did you make the patch?
[17:09] pieterh	staylor: if you can make cmake work in any way at all, send examples to the list
[17:09] sustrik	pieterh: git diff
[17:09] sustrik	want me to send the format-patch to the ML?
[17:10] pieterh	sustrik: or just send me the two files
[17:10] pieterh	i don't really care, just need a branch to test
[17:10] sustrik	wait a sec
[17:10] sustrik	snet
[17:10] sustrik	sent
[17:10] pieterh	sustrik: you could work with a fork of libzmq, then push branches to that easily
[17:11] pieterh	sustrik: ok, got the files, thanks
[17:14] pieterh	sustrik: afaic... it doesn't crash any longer but the subscriber gets the wrong chunk at some stage
[17:15] pieterh	gets 1000 bytes instead of 5
[17:15] pieterh	after some iterations
[17:15] pieterh	the publisher is stable now, however
[17:15] sustrik	ok
[17:16] pieterh	receiving
[17:16] pieterh	5
[17:16] pieterh	receiving
[17:16] pieterh	1000
[17:16] pieterh	sub: sub.c:26: main: Assertion `rc == 5' failed.
[17:16] pieterh	this is the kind of output, showing rc of first recv in loop
[17:17] sustrik	there are pub.c and sub.c from the gist, right?
[17:17] sustrik	these are
[17:22] pieterh	sustrik: yes
[17:22] sustrik	hm, i'm running it for 2 mins already
[17:22] sustrik	no assertions
[17:22] sustrik	version 3.0?
[17:22] pieterh	sustrik: what kind of box are you on?
[17:22] pieterh	I'll update the gist with the precise versions I'm using, they may have changed a little...
[17:23] sustrik	i'm using master head
[17:23] sustrik	+ the patch
[17:23] sustrik	the box is a dual core desktop
[17:23] pieterh	sure, I'm using master + the two files you sent
[17:23] sustrik	+ ubuntu
[17:23] pieterh	is it possible that the problem is related to threading concurrency?
[17:23] sustrik	i don't think so
[17:24] sustrik	looks like a pipe management problem
[17:24] sustrik	but anything is possible
[17:24] sustrik	what box you are on?
[17:24] pieterh	I'm on a 4-core desktop, Ubuntu
[17:24] sustrik	still no assertions here
[17:24] sustrik	let's wait couple of minutes more
[17:25] pieterh	well, it happens after 0.5 secs or so
[17:25] sustrik	hm
[17:25] pieterh	I've updated the gist (gists are full git repos, nice)... if you want to be 100% sure you're running the same test
[17:25] sustrik	\ok
[17:25] pieterh	oh... hang on...
[17:26] pieterh	sorry! i copied dist.cpp/hpp into the wrong directory
[17:26] pieterh	am running on plain master thus
[17:26] pieterh	duh....
[17:26] sustrik	interesting it didn't fail
[17:26] pieterh	it did fail, confused frames, as expected
[17:27] sustrik	ah, right
[17:27] pieterh	better now... no errors, no crashes...
[17:28] pieterh	fix confirmed on 3.0, thus
[17:28] pieterh	now to backport to 2.1...
[17:28] pieterh	were the changes to the patch significant?
[17:29] sustrik	wait a sec
[17:29] sustrik	there's one cosmetic change
[17:30] sustrik	removing a leftover function declaration from dist.hpp
[17:30] pieterh	ack
[17:30] sustrik	clear_new_pipes
[17:31] sustrik	and the real patch is in zmq::dist_t::write
[17:31] sustrik	these 4 lines:
[17:31] sustrik	pipes.swap (pipes.index (pipe_), active - 1);
[17:31] sustrik	active--;
[17:31] sustrik	pipes.swap (active, eligible - 1);
[17:31] sustrik	eligible--;
[17:31] sustrik	instead of original 2 lines
[17:31] pieterh	this is a patch on top of the patch, right?
[17:31] sustrik	yes
[17:31] pieterh	ack
[17:31] sustrik	pieterh: sorry, no
[17:32] sustrik	the patch i posted to gist
[17:32] sustrik	is the whole thing
[17:32] sustrik	the original patch + the patch of the patch
[17:32] pieterh	ok, since I applied the original patch manually I want to know if there's a shortcut
[17:32] pieterh	or if it's safer to redo that work
[17:33] sustrik	just use your existing codebase
[17:33] sustrik	and fix the 2 issues i've mentioned
[17:34] pieterh	ok
[17:34] pieterh	so if I do a diff of the two patches it will tell me what to actually change... :)
[17:35] pieterh	yeah, that does the trick
[17:35] pieterh	ok, will apply this, test, and let you know
[17:35] pieterh	am taking the kids for pizza now... bbl
[17:35] sustrik	cyl
[18:06] staylor	is it possible to both bind and connect with the same socket?
[18:09] Guthur	can't think why you would even want to do that
[18:09] sustrik	yes, it's possible
[18:10] sustrik	you can bind and connect as many times as you want
[18:14] staylor	okay, the reason I need to do that is I have many nodes that need to connect to each other to transfer session data. but depending on which can open a port for nat one node needs to bind or connect to his peer.
[18:14] staylor	I'm using a client and host socket right now, but a single socket to both bind and connect would be a lot cleaner if that's valid.
[18:18] staylor	should I be concerned about connecting to the same host twice? I could keep track of which I connected to but these connections are mostly few and far between.
[18:24] Guthur	oh, i miss understood, i read that as I bind and connect to the same address
[18:24] Guthur	with the same sockeet
[18:26] taotetek	anyone have a moment to help me find some clarity in regards to HWM options w/ PUSH / PULL socket types?
[18:27] sustrik	staylor: connecting twice means that the two connections will be treated as such
[18:27] sustrik	so for example you would get every message twice with a PUB/SUB sockets
[18:27] sustrik	taotetek: yes?
[18:28] taotetek	sustrik: so... (using pyzmq) .. if I set up a PUSH socket, and there are no PULL's connected, it blocks, which is what I expect
[18:29] taotetek	I'm looking at this passage in the documentation: "When a ZMQ_PUSH socket enters an exceptional state due to having reached the high water mark for all downstream nodes, or if there are no downstream nodes at all, then any zmq_send(3) operations on the socket shall block until the exceptional state ends"
[18:29] sustrik	yes
[18:29] taotetek	but I haven't been able to cause the PUSH socket to become blocked on a send
[18:29] taotetek	(unless no PULL sockets are connected)
[18:29] taotetek	so I'm either setting something wrong or not understanding what I'm reading
[18:29] sustrik	that's because messages are sent to the PULL socket in parallel
[18:30] sustrik	so you never reach the HWM
[18:30] sustrik	you can set the HWM on PULL socket
[18:30] sustrik	if you won't read from it
[18:30] sustrik	the HWM on the PULL socket would be reached
[18:31] sustrik	then the recv-side TCP buffer will be filled
[18:31] sustrik	then send-side TCP buffer will be filled
[18:31] sustrik	then PUSH socket buffer will reach HWM
[18:31] taotetek	ok.. so if I.. 1. set up a PULL socket with a HWM of 1, 2. set up a PUSH socket, 3. send from the PUSH socket but don't recv on the PULL
[18:31] sustrik	and block
[18:31] taotetek	then it will block once the tcp buffer is full
[18:31] taotetek	(and the tcp buffer could conceivably be larger than a single message?)
[18:32] sustrik	sure
[18:32] taotetek	which would be why I'm not seeing an immediate block
[18:32] sustrik	the default on linux iirc is 128kB
[18:32] taotetek	aha! ok I'll whip up a quick test
[18:32] taotetek	thank you sustrik, that's enormously helpful information
[18:32] sustrik	you are welcome
[18:33] staylor	sustrik, okay so if I have two xrep sockets x1,x2 where x1 binds and x2 connects twice, any message would go to x2 twice?
[18:34] taotetek	sustrik: and that makes perfect sense. it's easy when working with zmq to forget that it's still TCP under the hood sometimes I think, because it makes it so ridiculously easy to be "message" oriented.
[18:34] sustrik	staylor: nope, req/rep pattern sends message to a single connection
[18:35] sustrik	what'll you see would be load-balancing between the connections
[18:35] sustrik	and thus possible re-ordering of messages
[18:35] staylor	then x2 being the same socket connected twice to the same host would just receive a single message then
[18:36] sustrik	yes
[18:36] sustrik	with possible reordering
[18:36] staylor	alright
[18:36] staylor	my worry was that I want to know if I should check before connecting if I'm already connected to that host or just go ahead and connect regardless
[18:37] staylor	my network is effectively a mesh of xrep sockets which all bind, and then will also connect to the host they need to message.
[18:40] Guthur	ian barbers PHP presentation is very good in regards stable/unstable parts of your arch
[18:40] Guthur	worth watching, though it is nearly an hour long
[18:42] staylor	"ZeroMQ is the answer" video on the website?
[18:43] sustrik	i would recomment watching it as well
[18:43] sustrik	connecting every component to every other component using XREP sockets doesn't sound like an ideal architecture
[18:44] staylor	my problem is I want to have a single bind per node since they require opening a port over upnp, there's only a few nodes that communicate to each other though.
[18:45] Guthur	staylor, yep
[18:45] staylor	this might be in the video so let me know if I'm asking something already answered, but what would a 'smarter' architecture be for dealing with this problem?
[18:46] Guthur	when you add a bind to a node it becomes a stable node
[18:46] Guthur	though I think static is a better term
[18:47] Guthur	whereas if a node only connects to other static nodes it is unstable, or dynamic, can come and go
[18:47] Guthur	Ian explains it way better than me though
[18:47] staylor	that's why I bind to nodes that are able to open upnp ports, other nodes connect, there's a server that acts as a sync to let two peers decide which will bind and which will connect
[18:47] Guthur	with pretty pictures and everything
[18:48] staylor	I consider a upnp enabled node to be static
[18:50] th	pieterh: what i said earlier - was not correct, the pure-c example is not failing earlier. the behaviour is the same as with c++
[18:51] th	pieterh: http://thzn.de/0mq-mp-mix-pure-c/ thats the latest testcase
[19:11] th	i switched from 2.1 to 3.0 now. i changed zmq_{send,recv} to zmq_{send,recv}msg and it compiles again. but i get a 'errno: 11 (Resource temporarily unavailable)' on sending
[19:15] th	which is EAGAIN - but i did not choose NONBLOCKING
[22:10] Seta00	I just watched the ZeroMQ is the Answer talk, and it really is worth watching