| [Time] Name | Message |
|
[15:02] cremes
|
sustrik: question about this code snippet from all of the #xsend functions: http://pastie.org/965712
|
|
[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/_zmq.so: 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 _zmq.so
|
|
[17:56] versificateur
|
thanks i'll check
|
|
[17:56] guido_g
|
try: ldd /usr/local/lib/python2.6/dist-packages/zmq/_zmq.so
|
|
[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 http://www.zeromq.org/ ?
|
|
[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/local_lat.py perf/remote_lat.py): Adding time.sleep(1) to end of latency perf tests. - http://bit.ly/9WG3CU
|
|
[21:46] CIA-15
|
pyzmq: 03Brian Granger 07master * rc854731 10/ zmq/tests/test_reqrep.py : Adding tests for large message bug. - http://bit.ly/9bz1A0
|
|
[22:28] CIA-15
|
pyzmq: 03Brian Granger 07nocopy * rd939461 10/ (perf/local_lat.py perf/remote_lat.py): Adding time.sleep(1) to end of latency perf tests. - http://bit.ly/9WG3CU
|
|
[22:28] CIA-15
|
pyzmq: 03Brian Granger 07nocopy * rc854731 10/ zmq/tests/test_reqrep.py : Adding tests for large message bug. - http://bit.ly/9bz1A0
|
|
[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/local_lat.py
|
|
[22:28] CIA-15
|
pyzmq: perf/remote_lat.py - http://bit.ly/aj7iyy
|
|
[22:28] CIA-15
|
pyzmq: 03Brian Granger 07nocopy * r1c8fb86 10/ (4 files): Updating perf tests with copy/no-copy options and new API. - http://bit.ly/9Nf8pL
|
