Tuesday May 18, 2010

[Time] NameMessage
[15:02] cremes sustrik: question about this code snippet from all of the #xsend functions:
[15:02] cremes if the data buffer is detached, when zmq_msg_close gets called how does it release that (detached) memory?
[15:03] cremes it looks to me like the library is orphaning that data buffer
[15:03] cremes who owns the zmq_msg_t once it is handed off to send? does 0mq own it or the application?
[16:47] b1ng0 hello
[16:47] b1ng0 i had some questions on choosing the right messaging model for my application and could use some help
[16:53] b1ng0 anyone there?
[16:58] versificateur hello...
[16:59] versificateur i tried to compile pyzmq on ubtuntu 10.04 but i got this error
[17:00] versificateur ImportError: /usr/local/lib/python2.6/dist-packages/zmq/ undefined symbol: zmq_getsockopt
[17:00] versificateur If i could have some help here... :(
[17:05] b1ng0 doesn't look like anyone is here
[17:06] guido_g b1ng0: you should simply ask your questions, meta-questions are ignored mostly
[17:06] b1ng0 oh ok
[17:07] b1ng0 basically i have a server that needs to send a request to another group of servers and then receive data back. i have to send the request to all servers because i don't know which one has the data on it that i need
[17:07] b1ng0 so it seems like i need to broadcast the query to all servers
[17:07] b1ng0 and then one of the servers will send a reply back
[17:08] b1ng0 so it seems like a mix of multicast and then send/receive
[17:08] b1ng0 but publish-subscribe also seems like it might work
[17:08] guido_g yes, sound like pub/sub
[17:09] b1ng0 and why not multicast
[17:09] guido_g you're mixing things a bit, it seems
[17:09] guido_g multicast is a transport protocol like tcp
[17:10] b1ng0 ok true
[17:10] b1ng0 but why would using tcp be better in this case
[17:10] guido_g you can of course use multicast (epgm/pgm) w/ pub/sub
[17:10] guido_g i didn't say to use tcp
[17:11] b1ng0 does it make a difference on the size of the messages? the queries could be in the 20K range and the responses would be less
[17:11] b1ng0 ok well that is what i am trying to figure out, should it be multicast with pub/sub or just tcp
[17:11] guido_g you couldn't tell the difference
[17:13] b1ng0 ok i see
[17:13] b1ng0 and then on sending the reply back, it would just use a direct send?
[17:13] b1ng0 to the central server?
[17:14] guido_g you could use the same channel as for the request
[17:14] b1ng0 or would the central one also subscribe to each of the other servers
[17:15] b1ng0 hm ok i will test it out
[17:15] b1ng0 thank you so much
[17:29] guido_g versificateur: check if libzmq is found, it's needed by
[17:56] versificateur thanks i'll check
[17:56] guido_g try: ldd /usr/local/lib/python2.6/dist-packages/zmq/
[17:57] versificateur it's work now because i remove debian package i use to install zmq
[17:58] versificateur and install zmq from source
[18:00] cremes versificateur: zmq_getsockopt is only available in the github master; you probably have version 2.0.6 installed
[18:01] guido_g oh... :)
[18:01] versificateur yeah
[18:02] cremes heh
[18:02] versificateur but i finally remove these packages
[18:02] versificateur and compile with git source
[18:03] versificateur it seems that everything works
[18:03] cremes hopefully 2.0.7 will get released soon and the python bindings will be back in sync with a "supported" release
[18:05] versificateur i've another question...
[18:06] versificateur in a PUB/SUB model how could i make the publisher wait for subscibers connections?
[18:06] guido_g you don't
[18:06] guido_g it's like radio
[18:06] guido_g you simply don't know if someone is listening
[18:08] versificateur so once publisher started every message not handle by a subscriber is lost?
[18:08] guido_g right
[18:10] versificateur ... and when a subscriber is connected it immediately receive update message from publisher. right?
[18:10] guido_g yes
[18:11] versificateur thnks a lot
[18:11] guido_g np
[18:13] versificateur with all buzz around realtime web (twitter...) is zmq well suited to handle realtime web?
[18:13] guido_g not at all
[18:13] guido_g it's not web
[18:14] guido_g *cough*
[18:14] cremes versificateur: you should provide some actionscript bindings for zmq so we can use it from our browsers via flash!
[18:14] cremes ;)
[18:14] guido_g hehehe
[18:15] versificateur in the current platform i work on. I'm using zmq to dispacth json data
[18:18] versificateur cremes: i'm not really good with scripting languages so for the actionscript bindings i'm not the good guy :)
[18:22] versificateur do you think zmq can do the job (for my platform) and relay around 0.5-1kb json data ??
[18:22] guido_g can do what?
[18:24] versificateur dispatch small json data (around 0.5-1ko )
[18:25] guido_g why shouldn't it?
[18:25] guido_g the python bindings even have send_json and recv_json
[18:26] versificateur wow i dont even know
[18:26] guido_g did you read some of the things at ?
[18:27] versificateur yes but i didn't found json related topic
[18:28] guido_g what's the differnce between json and a string/octet-stream?
[18:28] guido_g data is data
[18:30] versificateur yes it's true...
[18:30] guido_g ømq does not interfere with the data sent
[18:31] guido_g and 1kb is not a message size to worry about
[18:32] guido_g there're some performance numbers on the site, somewhere...
[18:33] versificateur I just found them
[18:36] guido_g i'd say: if you don't have qdr infiniband or 10gb ethernet, don't worry :)
[18:38] versificateur :)
[18:40] versificateur I go back to my tricky python code thanks a lot
[18:40] guido_g have fun
[18:54] cremes versificateur: if you are using python, you can't be worried too much about performance!
[18:54] cremes (i'm a ruby guy, so i can say that with a straight face.)
[18:55] guido_g python is usually fast enough
[21:42] CIA-15 pyzmq: 03Brian Granger 07master * rd939461 10/ (perf/ perf/ Adding time.sleep(1) to end of latency perf tests. -
[21:46] CIA-15 pyzmq: 03Brian Granger 07master * rc854731 10/ zmq/tests/ : Adding tests for large message bug. -
[22:28] CIA-15 pyzmq: 03Brian Granger 07nocopy * rd939461 10/ (perf/ perf/ Adding time.sleep(1) to end of latency perf tests. -
[22:28] CIA-15 pyzmq: 03Brian Granger 07nocopy * rc854731 10/ zmq/tests/ : Adding tests for large message bug. -
[22:28] CIA-15 pyzmq: 03Brian Granger 07nocopy * r9f44c7c 10/ (3 files in 2 dirs):
[22:28] CIA-15 pyzmq: Merge branch 'master' into nocopy
[22:28] CIA-15 pyzmq: Conflicts:
[22:28] CIA-15 pyzmq: perf/
[22:28] CIA-15 pyzmq: perf/ -
[22:28] CIA-15 pyzmq: 03Brian Granger 07nocopy * r1c8fb86 10/ (4 files): Updating perf tests with copy/no-copy options and new API. -