Tuesday April 5, 2011

[Time] NameMessage
[03:36] realz lol turns out 0mq also uses netstrings for messages :D
[05:24] sustrik michaelgreene_: hi
[05:24] sustrik if you are seeing socket beeing blocked when it should not be
[05:24] sustrik strip down the test case to its minimal version
[05:24] sustrik and report it either on the mailing list or in bug tracker
[05:24] sustrik you can try to debug it yourself using gdb as well
[05:24] sustrik as for {r=26,w=27}, that's a socket pair, the fds
[06:39] mikko pieterh: 2-1 and 2-2 broken on win atm
[09:11] sustrik Guthur: btw, the NovaSparks you've mentioned
[09:12] Guthur sustrik__: yep
[09:12] sustrik the author of common lisp 0mq bindings is working for them
[09:12] Guthur ah, yes he did ask if I knew him
[09:12] Guthur he was actually quite interested in 0MQ
[09:13] pouete Hi all !
[09:13] sustrik morning
[09:13] Guthur I unfortunately had to rush off at the time and didn't get a proper chance to talk to him
[09:13] Guthur I need to improve my networking skills
[09:13] sustrik yes, i met him once as he lives quite close to here
[09:14] sustrik i think they are either using or considering 0mq use
[09:15] Guthur They are considering it afaia
[09:16] Guthur they offer a number of interconnect strategies
[09:17] Guthur it's cool tech, I hope they are successful
[09:18] Guthur Programming hardware with with CommonLisp is pretty neat, by the looks of VHDL i can see the motivation as well
[09:18] sustrik :)
[09:18] Guthur it's also very easy to make DSLs with CL which then helps at the customer end of the abstraction, win win
[09:44] Guthur sustrik__: What in your opinion is the biggest win of having zeromq in the kernel?
[09:56] jsimmons more people developing it :D
[09:57] sustrik :)
[09:57] sustrik well, it logically belongs there
[09:57] sustrik doing it in user space means spending half of the development effort
[09:58] sustrik trying to find workarounds around not being in the kernel
[09:58] sustrik and from business perspective, getting into mainline linux kernel means immense deployment base
[10:07] Guthur so more logistical wins as opposed to any performance benefits
[10:10] sustrik kind of
[10:10] sustrik and obviosuly, saner API is a big win
[10:10] sustrik for example, 0mq socket would a file descriptor
[10:10] sustrik no need for zmq_init and zmq_term
[10:10] sustrik and no associated waiting on zmq_term to send pending messages
[10:10] sustrik etc.
[10:23] pouete I have a question : ihave ubuntu 10.10 using the øMQ library, i am doing this : and, when i am importing from python ( import zmq) i get this error : . could it be a version missmatch ?
[10:23] pouete and how can i solve this problem ?
[10:31] Guthur pouete: personally, I think for sanity sake it is better to download the source for 0MQ directly, compile and install
[10:31] Guthur YMMV though
[10:31] sustrik looks like some old 2.0.x version
[10:32] pouete sustrik__: indeed, the test suite tell me that i have ZMQ version detected: 2.0.6
[10:32] pouete so, have to uninstall it first i suppose
[10:32] sustrik getsockopt was introduced in 2.0.7 iirc
[10:36] pouete A! seems better, aptitude didnt purged all the files
[10:37] pouete sorry : i didnt asked aptitude to purge all files :)
[10:43] pouete ERROR: test messages from memoryview (only valid for python >= 2.7) < i have this error and python == 2.6.6, do i have to considere this as a real error (install python => 2.7) or a minor feature i dont need (keep my python version )?
[11:41] private_meta hmm... dammit, need to rewrite the majordomo protocol for me alredy
[11:41] private_meta *already
[11:42] Guthur private_meta: you need to add to the spec?
[11:42] private_meta no
[11:42] private_meta well
[11:43] private_meta I need client-to-broker heartbeats
[11:43] private_meta that ain't possible in the current design
[11:43] private_meta not like that
[11:46] Guthur private_meta: not sure why you need that
[11:47] private_meta I just need it
[11:47] Guthur a client is strictly synchronous, so you could feasibly just timeout on any request
[11:47] Guthur no need for heartbeat
[11:47] private_meta no, it's async for me
[11:47] Guthur well then you have already left the spec
[11:48] Guthur you could maybe have the client as a worker as well
[11:48] Guthur or some such
[11:49] private_meta in a way that would be a nice idea
[11:49] private_meta that way I'd just have to implement worker-to-worker comm
[11:50] Guthur as long as the workers, brokers and clients full fill their contract per the spec I think you can get away with any connection pattern
[11:51] private_meta Well, I'd still have to change the spec in the way that the Client address would be the service name
[11:53] private_meta but that would be a less major change in the protocol
[11:53] private_meta hmm... it'd still change the implementation to some extent, gotta look into that
[11:54] Guthur afaics there is nothing in the spec that says a client can not use an explicit address
[11:55] Guthur though you would not fullful the "Clients SHOULD use a REQ socket "
[11:55] Guthur unless you use two sockets
[11:55] Guthur at the client/worker end
[11:56] Guthur actually the only way you could full fill the two connection contracts is by using two sockets
[11:56] Guthur imo
[12:55] ASY ZMQ sockets are connected in nature, which basically means that you can not do any type of auto-discovery on the network. I use UDP broadcasts to identify nodes on the network. I have to continue using UDP and then use ZMQ only when UDP broadcaster has located something. Am I correct about all of this?
[12:56] guido_g pub/sub over (e)pgm would do
[12:58] ASY ok, I have to look at PGM then. Thanks.
[13:35] jmslagle Morning peeps :)
[13:35] jmslagle Is the on the wire protocol documented anywhere?
[13:36] jmslagle Ooh I found it
[15:32] drbobbeaty sustrik: you around? I have an issue that popped up with ZMQ 2.1.4 and I wanted to see if you had any ideas on it.
[15:34] drbobbeaty If anyone can help, the problem is detailed here: and it's basically, that in encoder_t::message_ready() the function zmq_msg_size() is called and it seg faults.
[15:34] drbobbeaty I wonder if you have any ideas...
[15:36] guido_g bad logic, getting the size of a closed message
[15:38] drbobbeaty So is there anything I can do short of patching the zmq_msg_size() method and then submitting that?
[15:39] guido_g what?
[15:39] guido_g when you're closing the message it's gone
[15:40] drbobbeaty My code makes a zmq::message_t, and sends it out the socket. I'm assuming (maybe incorrectly) that the send() method copies the provided message so that it's available for sending when the socket gets around to it.
[15:40] drbobbeaty So I'm not purposefully closing it (in C++).
[15:40] guido_g you're simply plain wrong
[15:41] drbobbeaty I'm sorry.
[15:42] drbobbeaty Let me double-check the Guide, but I'm pretty sure I'm using code right out of there for this...
[15:42] guido_g the code in the paste is wrong, no matter where it came from
[15:43] drbobbeaty You mean the code in the gist I posted?
[15:43] guido_g what else?
[15:43] guido_g i can't see your code from here
[15:43] drbobbeaty Sorry for being dense here, but I just want to make sure.
[15:43] drbobbeaty The code in the gist is from the 2.1.4 tarball.
[15:44] drbobbeaty If it's wrong, then it's in that tarball that it's wrong.
[15:44] guido_g might be
[15:45] drbobbeaty If it's a new bug, then I'd be glad to patch the zmq_msg_size() to check the msg->context for NULL before the size check.
[15:45] drbobbeaty Or is there another error you see?
[15:46] guido_g the message is closed unconditionally and then the size is requested
[15:46] guido_g looks like a bigger issue
[15:47] guido_g but i'm not well versed in the core
[15:47] drbobbeaty I see - in the encoder... the message is destroyed, and then possibly init-ed again.
[15:48] Seta00 yeah but line 68 is only reached when the message is closed
[15:48] guido_g which sounds wrong
[15:48] drbobbeaty I'll send it to the mailing list and see see what Sustrik thinks... it does seem a little odd.
[15:48] guido_g ack
[15:49] Seta00 but I agree zmq_msg_size should assert the context
[15:49] guido_g the code doesn't make sense
[15:49] Seta00 I know
[15:49] guido_g at least w/o digging deeper
[15:50] Seta00 but still, segfaulting on a fairly common case like that is Bad.
[15:50] guido_g why is the message closed and accessed again afterwards?
[15:51] drbobbeaty I'm trying to put it all in a nice email to the list. All good points...
[15:52] guido_g good idea
[15:54] ianbarber pretty sure it doesn't copy when sending, else the zero copy method would be dubious.
[15:57] Seta00 yes, I remember having problems deleting the message right after sending it
[15:57] guido_g you shouldn't do that, see send man page
[16:27] mikko pieterh: MSVC issues with 2-1 and 2-2
[16:27] mikko builds: libzmq2-1_MSVC-win7 and libzmq2-2_MSVC-win7
[18:13] so_solid_moo hrm, has anyone seen this error before: usr/include/zmq.h:246:16: note: expected ‘struct zmq_pollitem_t *’ but argument is of type ‘struct zmq_pollitem_t *’
[18:13] so_solid_moo :S
[18:28] mikko so_solid_moo: looks odd
[18:28] so_solid_moo yeah :(
[21:04] geck so, I've been playing with the perl bindings and the 100-basic.t unit test is giving an erro about the default ZMQ_RATE value not being 100
[21:04] geck upon further checking, the value is actually 40000
[21:04] geck is this a case of a the test not being updated, or an indication of a more serious problem?
[21:05] geck steps to reproduce: `cpan ZeroMQ` after installing 2.1.14
[21:06] guido_g the value has been changed lately
[21:07] geck file issue on github? or is that handled via
[21:07] stutter if i have a push server set up, and 2 pull clients connected to there any way to build my app so that i can start a 3rd pull client and immediately alleviate load from the existing pull clients? (take over messages that have been sent on the push server, but not processed on the pull clients yet)
[21:08] guido_g stutter: this is the default behaviour
[21:08] guido_g the push will start sending messages to the 3rd client as soon it has connected itself
[21:08] stutter yeah, just wondering if i could tweak it to start doing work immediatley
[21:09] stutter new messages only, nothing in the queue gets re-routed
[21:09] guido_g true