ZeroMq IRC Log

Wednesday October 20, 2010

[Time] Name	Message
[09:20] mikko	sustrik: trying to sort out the access today
[09:20] sustrik	mikko: thanks
[09:20] mikko	ran into some issues last night as the box is behind firewalling that i have no access to
[09:20] mikko	so trying to setup a socks proxy to forward connection
[09:20] sustrik	ok
[09:20] mikko	but dante isn't the most pleasurable thing to config
[09:20] sustrik	however, if it's a problem, just let it be
[09:20] sustrik	i can install sun studio here
[09:23] mikko	sustrik: it's a challenge
[09:23] mikko	just need to nail the dante config tonight
[09:23] sustrik	:)
[09:23] sustrik	btw, nice that you've made an port 80 alias for the builds
[10:00] Nate75Sanders	If I have a sender A and a receiver B such that B can't keep up with A's message sends due to B being busy doing a lot of work, will the messages queue up on the sender or at the receiver? Additionally, is there a mechanism by which I can determine the length of the queue?
[10:10] sustrik	the messages are trasferred continuously
[10:10] sustrik	so some will be on the sender and some on the receiver
[10:11] sustrik	you can limit the size of the queue using ZMQ_HWM option
[10:11] Nate75Sanders	sustrik: But can I measure the length of the current queue?
[10:12] sustrik	no
[10:12] Nate75Sanders	sustrik: Or detect that I've hit the HWM?
[10:12] Nate75Sanders	sustrik: that would be fine, too
[10:13] sustrik	REQ or PUSH socket will block when hwm is reached
[10:13] Nate75Sanders	sustrik: ah, k -- that works
[10:14] Nate75Sanders	sustrik: Thank you...I've read through various parts of the guide a few times. Hard to keep it all in my head over the weeks. Is there a really concise guide with a grid showing behaviors or anything of that nature?
[10:15] sustrik	hm. mot really.
[10:15] sustrik	it would have to be N-dimensional grid...
[10:16] Nate75Sanders	sustrik: Sure. I do think something more concise than the guide (maybe several 2D grids) or something -- maybe even a "list of axioms" or something might be good.
[10:16] Nate75Sanders	sustrik: In any case, I'm sure I'll remember more with practice. What you have so far is definitely good.
[10:18] sustrik	you may want to put down notes as you are learning
[10:18] sustrik	and publish it afterwards
[10:18] Nate75Sanders	sustrik: ;) -- I'll see what I can do
[11:40] drbobbeaty	sustrik: I just emailed the mailing list that if I change my code to have unique port numers, the duplication on the receiver goes away. Since it appears that this is the better design (Steve's comments) I'm going to go that way anyway. I've updated the gists with the unique port numbers if you want to have a look, or you can change them back to the same thing to reproduce the issue.
[11:40] drbobbeaty	Just wanted to say thanks for helping me with this issue.
[11:41] drbobbeaty	Steve-o: if you're listening, thanks a million. It really helped.
[12:00] sustrik	drbobbeaty: good it works for you now
[12:01] sustrik	however, it's a pitfall
[12:01] sustrik	i'm going to look into how to make the whole thing more usable
[12:01] drbobbeaty	That would be fantastic. Very much appreciated.
[12:17] sustrik	drbobbeaty: please do revert the apps to the broken state
[12:17] sustrik	i'll use them to test the problem
[12:17] drbobbeaty	OK... doing that now.
[12:20] drbobbeaty	sustrik: I have reverted them.
[12:22] sustrik	thanks
[12:35] plq	sustrik, hi, i'm burak from the ml. got a minute?
[12:35] sustrik	hi burak
[12:35] sustrik	sure
[12:35] plq	howdy :)
[12:35] sustrik	going well :)
[12:36] sustrik	the copy stuff?
[12:36] plq	so you said "STL containers assure that the items stored are accessed from at most one thread at a time." <- i'm pretty sure that's not the case. maybe i misunderstand?
[12:36] plq	yep
[12:36] sustrik	well, STL containers are not thread-safe
[12:36] sustrik	meaning that application that use them don't access them from multiple threads at once
[12:36] plq	ok, so you ment "assume"
[12:37] sustrik	"assure" by failing when you don't do so :)
[12:37] plq	they can be accessed from multiple threads when they remain read only
[12:37] sustrik	true
[12:38] plq	sustrik, i thought by assure you meant that it set mutexes and such
[12:38] sustrik	which is ok as no copying happens in that case
[12:38] sustrik	nope
[12:38] sustrik	i've used a wrong word
[12:39] plq	right ok.
[12:39] plq	let me answer that to the ml.
[12:39] sustrik	ok
[14:01] Guest83789	Hi, I think found an error in the 0MQ Guide
[14:01] Guest83789	who do I talk to?
[14:08] cremes	Guest83789: you could open an issue on github for it with an explanation and a correction
[14:09] cremes	OR, sign up on the zeromq.org wiki and fix it yourself directly
[14:10] sustrik	i think the guide is generated from a raw text file source code
[14:10] sustrik	thus fixing it on wiki would be overwritten anyway later on
[14:10] sustrik	just send a fix to the mailing list and that's it
[14:16] Guest83789	ok, sounds nice
[14:17] Guest83789	hey, wikidot
[14:17] Guest83789	nice :)
[14:57] ukl	just curious - what does a subscriber (using a SUB socket, no fancy workarounds) do if there's no publisher (yet)? does it poll?
[15:00] sustrik	ukl: TCP?
[15:01] ukl	sustrik: it timeouts? (I don't know which tcp facilities would help here)
[15:02] sustrik	i mean, are you asking about TCP transport?
[15:03] ukl	oh sorry, yes I am
[15:04] sustrik	if you don't have SUB sockets
[15:04] sustrik	there are no TCP connections underneath the pub socket
[15:04] sustrik	so it does nothing
[15:06] ukl	ok thanks
[15:07] DerGuteMoritz	AIUI ukl's question is the other way around -- i.e. what do SUB sockets do if one doesn't have any PUB sockets
[15:08] sustrik	same answer: nothing
[15:09] DerGuteMoritz	I see
[15:09] DerGuteMoritz	I wonder how that's implemented, will definitely take a look :-)
[15:23] sustrik	heh
[15:23] sustrik	well, it's not really nothing
[15:24] sustrik	internally, it tries to read from a fd that connects it to the I/O threads
[15:24] sustrik	if there is nothing to read, it will just block
[15:24] DerGuteMoritz	and what causes the connection to be established?
[15:24] DerGuteMoritz	when using the tcp transport?
[15:25] sustrik	either you call zmq_connect
[15:25] sustrik	or the peer establishes the TCP connection
[15:25] DerGuteMoritz	peer == publisher in this case?
[15:25] sustrik	yes
[15:25] DerGuteMoritz	so the subscriber is actually listening?
[15:26] sustrik	if you call zmq_bind it's listening
[15:26] sustrik	if you call zmq_connect it connects
[15:26] sustrik	you can even do both
[15:26] DerGuteMoritz	interesting
[15:26] DerGuteMoritz	well but if I call zmq_connect
[15:26] DerGuteMoritz	and there is no publisher yet
[15:26] sustrik	it tries to connect in the background
[15:26] DerGuteMoritz	how does it know when to connect when it becomes available?
[15:27] DerGuteMoritz	so it polls?
[15:27] sustrik	it retries in periodic intercals
[15:27] DerGuteMoritz	riiiight
[15:27] sustrik	you cannot poll on non-existent conneciton
[15:27] DerGuteMoritz	I think that's what ukl was after
[15:27] DerGuteMoritz	well yeys, I meant periodic retries
[15:27] DerGuteMoritz	is there an option to set that interval?
[15:31] sustrik	in 2.0.x it's a compile-time option
[15:31] sustrik	see src/config.hpp
[15:31] sustrik	in master (2.1) it's a socket option
[15:31] sustrik	ZMQ_RECONNECT_IVL
[15:53] DerGuteMoritz	thanks for the info
[15:54] DerGuteMoritz	when creating a new language binding, should I rather use 2.0.x or the master branch?
[15:54] DerGuteMoritz	i.e. is a new release imminent?
[15:54] sustrik	it's more or less stabilised
[15:55] sustrik	it won't take long to release it
[15:55] DerGuteMoritz	alright
[15:55] sustrik	what binding are you planning?
[15:55] DerGuteMoritz	and it is not backwards compatible I guess?
[15:55] DerGuteMoritz	I have in fact almost finished it, it's for Chicken Scheme
[15:56] sustrik	it should be backward compatible
[15:57] DerGuteMoritz	ok nice
[15:57] DerGuteMoritz	my main motivation was to play with mongrel2 in Chicken, so I'd want it to be compatible :-)
[15:59] sustrik	i think zed is going to migrate to 2.1 anyway
[15:59] sustrik	anyway, it should make no difference
[16:00] DerGuteMoritz	gret
[16:00] DerGuteMoritz	*great
[16:00] DerGuteMoritz	I'll notify you guys when the binding is publicly available
[16:00] sustrik	thanks
[16:01] DerGuteMoritz	thank you, too!
[16:33] pieterh	Chicken?
[16:34] sustrik	chicken
[16:35] pieterh	two new bindings (for languages /me never knew existed) in one day... :-)
[16:35] sustrik	chicken is scheme afaik
[16:36] pieterh	aight, just reading about it...
[16:36] sustrik	the other one seems to be something lispy as well
[16:37] pieterh	hmm, Chicken looks real nice
[16:38] pieterh	0MQ as a language-exchange programme...
[16:46] DerGuteMoritz	heh, cool
[16:46] DerGuteMoritz	what was the other lispy thing,
[16:47] DerGuteMoritz	?
[16:51] ptrb	is it appropriate to set the HWM on a ZMQ_PUSH socket to 1 so it's treated as essentially blocking? or is HWM truly "exceptional" and shouldn't be relied upon in that way?
[16:53] sustrik	racket
[16:53] sustrik	HWM is size of your local buffer
[16:53] sustrik	it doesn't mean the whole thing would work in lock-step manner
[16:54] sustrik	some messages will be in TCP buffers
[16:54] sustrik	some are queued in the peer socket
[16:54] sustrik	etc.
[16:58] ptrb	"local buffer" within ZMQ though right
[16:58] sustrik	right
[16:59] ptrb	so really HWM=1 doesn't enforce that only one message is ever pending... it's more best-effort?
[17:01] DerGuteMoritz	racket, I see1
[17:02] DerGuteMoritz	yes, that is the former PLT scheme
[17:07] sustrik	ptrb: no, it's size of local buffer, that's it
[17:07] sustrik	no effort
[17:07] sustrik	just a limit on buffer
[17:09] ptrb	understood
[17:13] __Andi	Hi ho!
[17:14] sustrik	hi
[17:14] __Andi	sb here?
[17:15] sustrik	yes
[21:04] mikko	sustrik: here?