ZeroMq IRC Log

Wednesday November 10, 2010

[Time] Name	Message
[00:02] Guest37325	Hi all. I am having trouble installing pyzmq on windows. When running setup.py 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 ph@imatix.com 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 :)