Wednesday November 10, 2010

[Time] NameMessage
[00:02] Guest37325 Hi all. I am having trouble installing pyzmq on windows. When running install I get error: Cython-generated file 'zmq\core\constants.c' not found. Any ideas?
[00:10] Guthur Guest37325, If you don't get an answer here you could try the mailing list
[08:38] kyuss Morning.
[09:32] mikko morning
[09:49] mikko zomg: to answer your question from yesterday, mainly with C
[11:47] vini hello
[11:48] vini Anyone had problems with Windows Server 2008? (not R2)
[11:48] vini The ZeroMQ for me is very slow
[16:43] dv hello
[16:43] dv can i use pub/sub with multiple subscribers and ipc?
[16:44] dv I tried to bind to the ipc address twice, but it doesnt work as expected
[16:45] guido_g what does "it doesnt work as expected" mean?
[16:45] dv well, if I start the program twice, the two instances dont get messages from each other
[16:45] dv only from themselves
[16:45] dv as if I was using inproc instead of ipc
[16:46] guido_g put the programs and their paramters in a paste-bin, please
[16:48] dv oh hold on
[16:48] dv i just noticed
[16:48] guido_g yes?
[16:48] dv I bind to the same address twice
[16:48] dv doesnt work with tcp of course, and I presume it wont work with ipc either, right?
[16:49] guido_g good question
[16:54] guido_g yeah, 2 binds are not allowed it seems
[17:05] dv ok, so i was trying to write a chat program, just to test out zeromq
[17:05] dv using pub-sub
[17:05] dv multicasting for inter-host communication, and ipc for chat programs that run on the same host
[17:06] dv would you also use epgm for chatting between hosts and ipc for chats in the same host?
[17:11] guido_g depends on the use-case
[17:13] dv hm. i am tring to do this serverless.
[17:14] dv guido_g: what other info is necessary?
[17:14] guido_g for what?
[17:14] dv <guido_g> depends on the use-case
[17:14] guido_g yes
[17:14] dv isnt what I write a use case?
[17:15] guido_g no really
[17:15] guido_g *not
[17:18] guido_g youc could simply use epgm for all participants, i can't see a benefit in using ipc here
[17:18] dv you cant use epgm for communicating on the same host
[17:19] dv well, you can, but IIRC it requires the multicast loopback hack,
[17:19] dv which is strongly discouraged
[17:19] guido_g hack? it's a socket option
[17:21] dv i had a discussion about this yesterday I think
[17:21] guido_g or what do you mean?
[17:21] dv it is recommendeed to set ZMQ_MCAST_LOOP to 0,
[17:21] guido_g do you men the loopback network device?
[17:22] dv oh hold on.
[17:22] dv i might have a logical error here.
[17:22] guido_g "Leaving multicast loopback enabled when it is not required can have a negative impact on performance." <- from the docs
[17:22] dv i'll try something, just a sec
[17:23] guido_g scho' recht :)
[17:23] pieterh dv_ for a chat program you really don't care too much about performance
[17:23] pieterh my advice would be to start simple
[17:23] pieterh pub sub over tcp, period
[17:23] pieterh and use a server :-)
[17:24] pieterh it is significantly simpler than using multicast
[17:24] pieterh further, any real 0MQ application does end up using servers (devices, minibrokers, etc)
[17:24] pieterh so it's worth exploring how that works, it's a big part of "testing 0MQ"
[17:29] mikko howdy
[17:32] dv pieterh: already noticed. i just find multicasting appealing for nodes that communicate with each other
[17:32] dv pieterh: but maybe i'll try that, yeah.
[17:32] pieterh mikko, howdy
[17:33] pieterh dv_, I'd recommend only doing multicast once you've grokked the unicast patterns
[17:33] kisielk pieterh: sorry about not mailing the list for that patch, it was late night and I didn't think of it :)
[17:33] dv pieterh: its not just performance, its also resilience - a server is a single point of failure, something i have to fight at work with
[17:33] dv pieterh: so this chat thing is also a learning experience, ultimately i would use this also for discovery
[17:33] pieterh dv_, sure, there are solutions to that, usually making redundant devices
[17:34] dv pieterh: this is what we do, and it is nontrivial
[17:34] pieterh dv_, indeed, reliability is always hard work
[17:34] pieterh multicast can help in some cases
[17:35] pieterh but the real answer is to make simpler pieces that are much less likely to crash
[17:35] Guthur pieterh, Did you get my second batch of clrzmq2 examples sent to the ML?
[17:36] pieterh Guthur, yup, I did
[17:36] pieterh didn't I confirm, sorry...
[17:36] pieterh btw getting a tarball is actually a lot easier than git pull requests...
[17:36] dv it is?
[17:36] pieterh yeah
[17:36] dv oh, for patches you mean
[17:37] pieterh i sometimes get git merges go inexplicably weird and then I'm left with a mess
[17:37] Guthur pieterh, Oh sorry I see the confirmation now
[17:37] Guthur my bad
[17:37] pieterh np :-)
[17:37] pieterh it's good to double check
[17:37] Guthur I never had them on git so it was easier for me
[17:38] pieterh ok, I need to leave... if anyone ever needs my attention here on irc just ping me at and I'll try to come on
[17:38] Guthur bye pieterh
[17:39] pieterh bye Guthur
[23:10] Led_Zeppelin is there a way to do kernel bypass?
[23:25] igrigorik hey all.. question: if i'm using upstream/downstream sockets.. is there any way to actually limit the number of messages in flight? as in, blocking semantics on downstream until some messages are consumed on upstream?
[23:27] igrigorik my understanding is that HWM should allow me to control this, but it doesn't appear to be doing the trick
[23:33] Guthur igrigorik, HWM marker is a point where messages went to be sent will start to get dropped
[23:33] Guthur went/about
[23:34] Guthur It does not limit the number of messages in flight
[23:34] igrigorik right, ok.. so its just the sender's buffer
[23:34] Guthur igrigorik, yep
[23:34] Guthur more or less, from my understanding
[23:34] igrigorik so there is no way for me to actually "control" the number of inflight packets, easily, at least
[23:35] Guthur I think you would have to engineer that
[23:35] Guthur some sort of ack signal
[23:38] igrigorik right, ugh :-)
[23:39] Guthur Maybe a more experience user can come along and offer a simple solution
[23:39] Guthur I'm rather green when it comes to 0MQ
[23:40] igrigorik that makes the two of us :)
[23:40] igrigorik if there was a simple solution for this.. that would make my life much simler
[23:40] igrigorik *simpler
[23:40] Guthur hehe, well at least it would be good practice to develop some sort of ack signal
[23:41] Guthur The sender will stop when the count reaches your make amount in flight, and the count is decrement each time the sender receives and acknowledgement of receipt
[23:42] Guthur Its actually only a few lines of code in ZMQ
[23:42] Guthur in/with
[23:42] Guthur what language?
[23:44] igrigorik ruby.. but this stuff can get tricky
[23:45] igrigorik i guess you can have a separate control channel which can monitor the flow
[23:45] igrigorik but if you have a device in the middle (multiple consumers for example, and multiple producers).. oi
[23:45] igrigorik hmm
[23:45] igrigorik maybe i'm making it more complicated than it should be
[23:46] igrigorik (usually the case :-))
[23:46] Guthur igrigorik, Will you can use the IDs
[23:46] Guthur of the sockets that sent the messages
[23:47] igrigorik in the pub-sub case, yeah, that would work I think
[23:47] Guthur If I didn't have to go to bed soon I'd actually be tempted to implement something for the fun, hehe
[23:51] Guthur ok, time for sleep, enjoy your hacking igrigorik
[23:51] igrigorik thanks :)