Friday February 11, 2011

[Time] NameMessage
[00:06] cremes eut:
[00:06] cremes that might help
[00:08] eut great :]
[04:47] gui81 anyone here
[04:47] gui81 this is my first time joining an irc chat, is this working
[04:57] gui81 has anyone solved the async client problem, or does anyone have an example using zmq_poll
[04:58] gui81 Matt talks about this issue in the comments section on
[05:01] gui81 another question I have is whether or not it is possible to publish and subscribe on the same port number, I have tried a simple example, that compiled just fine, but it locked up my computer and I had to reboot
[05:04] gui81 the multithreaded server example in the link above requires that you send, receive, send, receive, etc..., but I want to be able to send a message and maybe send a few more messages before a response is actually received. This is so that I don't have to wait on a request that could take a potentially long time
[05:07] gui81 I could use pub/sub and rethink how I handle messages, but I was hoping I could do this over the same port
[05:10] guido_g publisher and subscriber should of course use the same port, otherwise they couldn't talk to each other
[05:11] gui81 I'm saying that I want a single process to both publish and subscribe like the following:
[05:12] gui81 zmq::socket_t publisher(context, ZMQ_PUB);
[05:12] guido_g doesn't matter
[05:12] guido_g publisher sends things out and subscriber needs to get the information
[05:12] guido_g so both need to share a communication path
[05:13] gui81 publisher.bind("tcp://*:5563");
[05:13] gui81 zmq::socket_t subscriber(context, ZMQ_SUB);subscriber.connect("tcp://localhost:5564");
[05:13] guido_g wouldn't work
[05:13] gui81 sorry, let me try that again
[05:13] guido_g did you ever to network stuff befeore?
[05:13] guido_g s/to/do/
[05:14] gui81 zmq::context_t context(1);
[05:14] gui81 zmq::socket_t publisher(context, ZMQ_PUB);
[05:14] gui81 publisher.bind("tcp://*:5563");
[05:14] gui81 // don't do this on the same port as above, will have to reboot computer
[05:14] gui81 zmq::socket_t subscriber(context, ZMQ_SUB);
[05:14] gui81 subscriber.connect("tcp://localhost:5563");
[05:14] gui81 subscriber.setsockopt( ZMQ_SUBSCRIBE, "C", 1);
[05:15] guido_g i don't know your computer and what you've done elsewhere, but the principle is right
[05:15] guido_g and for code please use a pastbin like or
[05:17] guido_g next thing: if you have trouble w/ something, write a minimal example that shows the problem and show the complete code and describe the expeceted vs. the observed behaviour
[05:18] gui81 are you suggesting i post my code on a website?
[05:18] guido_g yes
[05:28] gui81 guido_g, I think I figured out what I was doing wrong with my pub/sub stuff. looks like I was trying to bind on both sides. Turns out this compiled just fine, but after running it, it would lock up. I even had to reboot, kill -9 wasn't working. I am running on a Mac. When I switched to only using one bind with multiple connects, things started working.
[05:30] gui81 does anyone have any examples on an async client like what is suggested on by Matt in the comments section
[05:31] guido_g did you read the guide?
[05:31] gui81 yes
[05:33] gui81 using req/rep it looks like you always have to send, receive, send, receive. If I want to send, send, receive, send, receive, recieve how would I do it, are there examples out there
[05:34] guido_g use xreq/xrep sockets
[05:40] gui81 do you know of an example showing how to use xreq/xrep for something similar to the scenario i mentioned? all of the examples in the guide look like they are used when kicking off worker threads
[05:41] guido_g frankly, i don't know what you intend
[05:42] guido_g if you have threads just let them talk via xreq/xrep
[05:44] gui81 I would like to be able to do something similar to: s.send (request, callback); where the sending thread won't be blocked and the application can send more requests. then the callback is invoked whenever a reply is received for that request
[05:45] guido_g a) ØMQ doesn't do callbacks, you should have discovered that by now
[05:46] guido_g b) go read the XREQ/XREP docs again, there is no need for waiting or blocking
[05:47] gui81 I understand they don't do callbacks, but if I can build a wrapper that would function similar to the callback, then that would work for me. if this is possible with xreq/xrep then I will try to look further into this type of socket. I admit that I don't know much about zeromq since I just started reading the guide today. Thanks for the help.
[05:48] guido_g then finish reading the guide and the docs, will make a lot of things much clearer
[05:49] jugg I've had a system running for a couple of weeks, with zeromq built off of commit: 56bdba - and I just had the following assertion occur while running another round of stress tests: "Assertion failed: inpipes [current_in].active (xrep.cpp:229)" Can that assert occur because of usage error, or why?
[05:49] guido_g ahh... and don't expect cookbook like examples suited for your use-cases
[05:53] jugg irc logs show another instance of this assertion at
[06:10] bitweiler i notice in the zeromq-FAQ that it doesn't provide protocol buffering; what is the purpose of such said buffering?
[06:14] guido_g which faq item you're reffering to?
[06:16] guido_g s/reffering/referring/
[06:16] guido_g need more coffee
[06:16] bitweiler sorry, i meant serializing data to/from the wire representation
[06:17] bitweiler guido_g: this FAQ:
[06:18] bitweiler Does ØMQ include APIs for serializing data to/from the wire representation? what is the purpose of such serializing?
[06:19] guido_g as stated, there is no such api in ømq
[06:20] guido_g and serialization in the context of messaging means to convert a data strcuture into/from a byte stream for transfer
[06:23] guido_g bitweiler: hope that answers your question
[06:24] bitweiler yes, thanks
[06:24] guido_g great, i gotta run now... :)
[07:30] Guthur sustrik, ping
[08:24] bitweiler quick question, in the wuserver.c example from the guide what's the purpose of the within statement?
[08:30] sustrik morning
[08:30] bitweiler good day sustrik
[09:31] pieterh bitweiler: it produces a random number between 0 and N
[09:31] pieterh sorry that it's a bit cryptic, I'll change that
[10:01] sustrik pieterh: seems like there's something wrong with the mailing list
[10:01] sustrik i've sent a message there 5 mins ago
[10:01] sustrik and it's still not there
[10:05] mikko good morning
[10:31] sustrik kaib: pong
[10:32] sustrik Guthur: pong
[10:36] kaib sustrik: hi there
[10:36] kaib sustrik: i'm toying around with a freshly written 0mq protocol stack and was looking into how the wire protocol works.
[10:37] kaib sustrik: my aim is to write a prototype to see if a messaging based solution could be a good replacement for rpc in our system.
[10:37] sustrik kaib: speaking of 0mq over TCP?
[10:38] kaib sustrik: being wire compatible with 0mq seems like a good idea
[10:38] kaib sustrik: TCP initially, maybe UDP and other protocols later.
[10:38] sustrik there's no UDP transport for 0MQ so far...
[10:38] sustrik just PGM multicast
[10:38] sustrik anyway
[10:38] sustrik see zmq_tcp(7) man page
[10:38] sustrik there's 0mq framing described
[10:39] kaib sustrik: yep, i saw the line level framing
[10:39] sustrik ok
[10:39] mikko kaib: you could probably get prototype running pretty quickly by using zeromq and ZFL RPC
[10:39] sustrik as for the wire protocol on top of that
[10:39] kaib sustrik: i was wondering about the framing used by the different ports
[10:39] sustrik it's different for different messaging patterns
[10:39] sustrik REQ/REP
[10:39] sustrik PUB/SUB
[10:39] sustrik PUSH/PULL
[10:40] kaib mikko: what is ZFL RPC?
[10:40] mikko
[10:40] mikko
[10:40] sustrik you can think of each pattern as a separate protocol on top of basic 0mq framing
[10:40] sustrik which one are you interested in?
[10:40] kaib sustrik: pub/sub push/pull req/rep, in that order.
[10:41] kaib sustrik: we have all those patterns in the system..
[10:41] sustrik pub/sub and push/pull are easy
[10:41] sustrik the only specific so far is that the first message sent be each peer is identity
[10:41] sustrik (see ZMQ_IDENTITY socket option)
[10:42] kaib sustrik: what does the peer do with the identity?
[10:42] sustrik if no identity is set, empty message is sent
[10:42] sustrik it can use when reconnection happens
[10:42] kaib sustrik: i understood it's used for persisting messages between crashes (presumably somewhere on disk?)
[10:42] sustrik if the new connection has same identity as one previously broken
[10:42] sustrik it can reuse the resources allocated for the old one
[10:43] sustrik so it can hold messages in the memory (or swap them to the disk) while the peer reconnects
[10:44] sustrik as for REQ/REP see here:
[10:44] kaib sustrik: ok, so it's useful for making sure that no messages are dropped even if the client disconnects, right?
[10:45] sustrik messages can still be lost if they were processed or "on-the-wire" during the failure
[10:45] sustrik but it makes the whole thing more reliable, yes
[10:45] sustrik aside of that identities are used for routing replies to the original requesters in REQ/REP pattern
[10:45] sustrik see the link above
[10:45] sustrik there's a picture showing how it works
[10:46] sustrik kaib: btw, why write a new messaging solution?
[10:47] sustrik i'm not discouraging you, but it takes some manyears to get that done
[10:47] kaib sustrik: curiosity mostly, partially to see if a native implementation could be better integrated.
[10:48] kaib sustrik: we run a cluster consisting of ~50 nodes (we are still in pre launch) with the servers all written in Go.
[10:48] kaib sustrik: i was looking into hooking up mongrel2 as our http server and started reading more about 0mq.
[10:48] sustrik kaib: sure
[10:49] kaib sustrik: it seems like pattern used in 0mq is actually quite nice.
[10:49] kaib sustrik: i've used messaging systems back at Google but never really grokked them, the rpc system is so much more common.
[10:49] sustrik the patterns are the most interesting part of 0mq i think
[10:50] kaib sustrik: our main pain point is complexity we run 6 distinct server types with some very complex and latency sensitive interactions.
[10:50] kaib sustrik: i have a gut feeling that messages might be a good fit, but i need to write some code to make sure that's true.
[10:51] sustrik give it a try
[10:51] kaib sustrik: i'm not trying to do a generic library, just something that fits our specific purpose. i'll probably open source it when we have time, but it's definitely just to scratch our own itch.
[10:51] sustrik well, good luck
[10:51] kaib sustrik: given the core 0mq library is pretty good .. :-)
[10:52] sustrik you know, i've seen loads of ad hoc messaging library projects running into troubles
[10:52] sustrik it looks easy when you start
[10:52] kaib what type of issues do they usually encounter?
[10:53] sustrik all kind of asynchronicity issues
[10:53] sustrik also scaling issues
[10:53] sustrik everything works ok in test env
[10:53] sustrik then when you move to production you start to exprience bottlenecks
[10:54] kaib yep, that seems to be a common pattern for all distributed code.
[10:54] sustrik later on it turns out that the bottleneck can't be avoided without rewriting the whole code from scratch
[10:54] sustrik etc.
[10:54] kaib are the perf problems mostly in userspace or in interactions with the kernel?
[10:54] sustrik both
[10:56] kaib i'd love to know more specifics, obviously that's something i'd rather avoid .. are the difficulties related to messaging systems or just concurrent/parallel code in general?
[10:56] kaib ie. do the people running into trouble have experience with writing distributed systems?
[10:56] sustrik sure
[11:01] sustrik for example, there's some 12 manyears altogether spent on 0mq + many more years of messaging experience from beforehand
[11:02] sustrik but we still run into this kind of trouble occassionally
[11:02] sustrik say: what happens it 500 peers decide to disconnect at exactly the same moment?
[11:02] sustrik what's the latency impact for the remaining peers?
[11:03] sustrik how does the number of cores on the system affect the impact
[11:03] sustrik etc.
[11:03] sustrik complex stuff
[11:04] Guthur sustrik: Sorry I was not watching there
[11:04] Guthur I was hoping to pick your brains a little regarding the polling classes in 0MQ
[11:04] sustrik sure
[11:04] sustrik shoot
[11:05] Guthur I was investigating in relation to implementing windows named pipes
[11:05] Guthur is the polling used internally by 0MQ
[11:05] Guthur and are all the events required?
[11:05] sustrik what events?
[11:05] Guthur eg POLLIN, POLLOUT, and POLLERR
[11:06] sustrik that's used in POSIX poll()
[11:06] sustrik 0mq virtualises the polling mechanism
[11:06] sustrik and from the user's perspective you have these events:
[11:06] sustrik in_event
[11:06] sustrik out_event
[11:07] sustrik timer_event
[11:07] kaib sustrik: thanks, i'll tinker around a bit and see what i get. we can always fall back on using the ref implementation if push comes to shove.
[11:07] sustrik (these are callbacks invoked by the poller class)
[11:07] sustrik kaib: sure
[11:07] Guthur ok, sorry I'll be right back
[11:07] Guthur need to go into a conf call
[11:07] Guthur sorry about this
[11:09] Guthur I was checking out select_t, poll_t, epoll_t, devpoll_t and kqueue_t, as you recommended
[11:09] Guthur is there anywhere else in particular I should look?
[11:10] sustrik nope, just implement the same interface with IOCP
[11:10] sustrik ah
[11:11] sustrik you should also redefine fd_t
[11:11] sustrik to resolve to HANDLE instead of SOCKET
[11:11] Guthur Named Pipes in MSWin obviously don't have a poll, all they have is call back functions on completion
[11:11] Guthur ok
[11:12] sustrik afaiu you can use ReadFile/WriteFile
[11:12] sustrik and IOCP for polling
[11:12] sustrik check that out first though
[11:14] Guthur yeah ReadFile/WriteFile sync, or ReadFileEx/WriteFileEx async
[11:15] Guthur each of those accept a completion callback function
[11:15] Guthur umm I haven't seen this IOCP
[11:15] Guthur I'll check that out
[13:28] zchrish Question about exceptions and C++ : When a user gives a bogus hostname, the code asserts. Can I catch the error; what is the accepted alternative to dying in this case?
[13:28] zchrish This is on a connect.
[13:29] drbobbeaty You're going to need to check the data before you pass it to zmq. The assert() is not "catchable" like an exception is.
[13:31] zchrish I see; thank you.
[14:46] ianbarber pieterh: re DPC talk, will do, I was just waiting to see if i'll be doing it at confoo in canada as well (already speaking there about solr, they asked if I could do another). Not that it takes much longer to update twice
[14:52] ianbarber i do hope this talk doesn't suck! different sort of audience with PHP devs to your fosdem one, not so much multithreading being discussed :)
[14:56] sustrik that makes the talk more interesting imo
[17:27] mikko pieterh: there?
[18:52] Guthur do we have a way of executing unit tests on the build server?
[18:53] Guthur or is that outside the remit
[19:13] sustrik Guthur: make check is executed when zmq is built
[19:14] Guthur i wonder if I could get something similar set up for clrzmq1
[19:15] Guthur clrzmq2*
[19:19] Guthur mikko, you about?
[21:29] CIA-21 jzmq: 03Nathan Marz 07master * r7983d5c 10/ src/Socket.cpp : fix type for args to linger from github issue #26 -
[21:29] CIA-21 jzmq: 03Gonzalo Diethelm 07master * r306e3b8 10/ src/Socket.cpp : Arranged proposed changes a bit, and added a cast to avoid a warning. -