Friday April 29, 2011

[Time] NameMessage
[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
[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++:
[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
[16:09] mikko sustrik: build failure
[16:10] sustrik let me see
[16:10] mikko
[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 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: 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