ZeroMq IRC Log

Friday February 11, 2011

[Time] Name	Message
[00:06] cremes	eut: http://www.zeromq.org/tutorials:xreq-and-xrep
[00:06] cremes	that might help
[00:08] eut	great :]
[04:47] gui81	anyone here
[04:47] gui81	this is my first time joining an irc chat, is this working
[04:57] gui81	has anyone solved the async client problem, or does anyone have an example using zmq_poll
[04:58] gui81	Matt talks about this issue in the comments section on http://www.zeromq.org/blog:multithreaded-server
[05:01] gui81	another question I have is whether or not it is possible to publish and subscribe on the same port number, I have tried a simple example, that compiled just fine, but it locked up my computer and I had to reboot
[05:04] gui81	the multithreaded server example in the link above requires that you send, receive, send, receive, etc..., but I want to be able to send a message and maybe send a few more messages before a response is actually received. This is so that I don't have to wait on a request that could take a potentially long time
[05:07] gui81	I could use pub/sub and rethink how I handle messages, but I was hoping I could do this over the same port
[05:10] guido_g	publisher and subscriber should of course use the same port, otherwise they couldn't talk to each other
[05:11] gui81	I'm saying that I want a single process to both publish and subscribe like the following:
[05:12] gui81	zmq::socket_t publisher(context, ZMQ_PUB);
[05:12] guido_g	doesn't matter
[05:12] guido_g	publisher sends things out and subscriber needs to get the information
[05:12] guido_g	so both need to share a communication path
[05:13] gui81	publisher.bind("tcp://*:5563");
[05:13] gui81	zmq::socket_t subscriber(context, ZMQ_SUB);subscriber.connect("tcp://localhost:5564");
[05:13] guido_g	wouldn't work
[05:13] gui81	sorry, let me try that again
[05:13] guido_g	did you ever to network stuff befeore?
[05:13] guido_g	s/to/do/
[05:14] gui81	zmq::context_t context(1);
[05:14] gui81	zmq::socket_t publisher(context, ZMQ_PUB);
[05:14] gui81	publisher.bind("tcp://*:5563");
[05:14] gui81	// don't do this on the same port as above, will have to reboot computer
[05:14] gui81	zmq::socket_t subscriber(context, ZMQ_SUB);
[05:14] gui81	subscriber.connect("tcp://localhost:5563");
[05:14] gui81	subscriber.setsockopt( ZMQ_SUBSCRIBE, "C", 1);
[05:15] guido_g	i don't know your computer and what you've done elsewhere, but the principle is right
[05:15] guido_g	and for code please use a pastbin like https://gist.github.com/ or http://paste.pocoo.org/
[05:17] guido_g	next thing: if you have trouble w/ something, write a minimal example that shows the problem and show the complete code and describe the expeceted vs. the observed behaviour
[05:18] gui81	are you suggesting i post my code on a website?
[05:18] guido_g	yes
[05:28] gui81	guido_g, I think I figured out what I was doing wrong with my pub/sub stuff. looks like I was trying to bind on both sides. Turns out this compiled just fine, but after running it, it would lock up. I even had to reboot, kill -9 wasn't working. I am running on a Mac. When I switched to only using one bind with multiple connects, things started working.
[05:30] gui81	does anyone have any examples on an async client like what is suggested on http://www.zeromq.org/blog:multithreaded-server by Matt in the comments section
[05:31] guido_g	did you read the guide?
[05:31] gui81	yes
[05:33] gui81	using req/rep it looks like you always have to send, receive, send, receive. If I want to send, send, receive, send, receive, recieve how would I do it, are there examples out there
[05:34] guido_g	use xreq/xrep sockets
[05:40] gui81	do you know of an example showing how to use xreq/xrep for something similar to the scenario i mentioned? all of the examples in the guide look like they are used when kicking off worker threads
[05:41] guido_g	frankly, i don't know what you intend
[05:42] guido_g	if you have threads just let them talk via xreq/xrep
[05:44] gui81	I would like to be able to do something similar to: s.send (request, callback); where the sending thread won't be blocked and the application can send more requests. then the callback is invoked whenever a reply is received for that request
[05:45] guido_g	a) ÃMQ doesn't do callbacks, you should have discovered that by now
[05:46] guido_g	b) go read the XREQ/XREP docs again, there is no need for waiting or blocking
[05:47] gui81	I understand they don't do callbacks, but if I can build a wrapper that would function similar to the callback, then that would work for me. if this is possible with xreq/xrep then I will try to look further into this type of socket. I admit that I don't know much about zeromq since I just started reading the guide today. Thanks for the help.
[05:48] guido_g	then finish reading the guide and the docs, will make a lot of things much clearer
[05:49] jugg	I've had a system running for a couple of weeks, with zeromq built off of commit: 56bdba - and I just had the following assertion occur while running another round of stress tests: "Assertion failed: inpipes [current_in].active (xrep.cpp:229)" Can that assert occur because of usage error, or why?
[05:49] guido_g	ahh... and don't expect cookbook like examples suited for your use-cases
[05:53] jugg	irc logs show another instance of this assertion at http://travlr.github.com/zmqirclog/2010-November.html
[06:10] bitweiler	i notice in the zeromq-FAQ that it doesn't provide protocol buffering; what is the purpose of such said buffering?
[06:14] guido_g	which faq item you're reffering to?
[06:16] guido_g	s/reffering/referring/
[06:16] guido_g	need more coffee
[06:16] bitweiler	sorry, i meant serializing data to/from the wire representation
[06:17] bitweiler	guido_g: this FAQ: http://www.zeromq.org/area:faq
[06:18] bitweiler	Does ÃMQ include APIs for serializing data to/from the wire representation? what is the purpose of such serializing?
[06:19] guido_g	as stated, there is no such api in Ã¸mq
[06:20] guido_g	and serialization in the context of messaging means to convert a data strcuture into/from a byte stream for transfer
[06:23] guido_g	bitweiler: hope that answers your question
[06:24] bitweiler	yes, thanks
[06:24] guido_g	great, i gotta run now... :)
[07:30] Guthur	sustrik, ping
[08:24] bitweiler	quick question, in the wuserver.c example from the guide what's the purpose of the within statement?
[08:30] sustrik	morning
[08:30] bitweiler	good day sustrik
[09:31] pieterh	bitweiler: it produces a random number between 0 and N
[09:31] pieterh	sorry that it's a bit cryptic, I'll change that
[10:01] sustrik	pieterh: seems like there's something wrong with the mailing list
[10:01] sustrik	i've sent a message there 5 mins ago
[10:01] sustrik	and it's still not there
[10:05] mikko	good morning
[10:31] sustrik	kaib: pong
[10:32] sustrik	Guthur: pong
[10:36] kaib	sustrik: hi there
[10:36] kaib	sustrik: i'm toying around with a freshly written 0mq protocol stack and was looking into how the wire protocol works.
[10:37] kaib	sustrik: my aim is to write a prototype to see if a messaging based solution could be a good replacement for rpc in our system.
[10:37] sustrik	kaib: speaking of 0mq over TCP?
[10:38] kaib	sustrik: being wire compatible with 0mq seems like a good idea
[10:38] kaib	sustrik: TCP initially, maybe UDP and other protocols later.
[10:38] sustrik	there's no UDP transport for 0MQ so far...
[10:38] sustrik	just PGM multicast
[10:38] sustrik	anyway
[10:38] sustrik	see zmq_tcp(7) man page
[10:38] sustrik	there's 0mq framing described
[10:39] kaib	sustrik: yep, i saw the line level framing
[10:39] sustrik	ok
[10:39] mikko	kaib: you could probably get prototype running pretty quickly by using zeromq and ZFL RPC
[10:39] sustrik	as for the wire protocol on top of that
[10:39] kaib	sustrik: i was wondering about the framing used by the different ports
[10:39] sustrik	it's different for different messaging patterns
[10:39] sustrik	REQ/REP
[10:39] sustrik	PUB/SUB
[10:39] sustrik	PUSH/PULL
[10:40] kaib	mikko: what is ZFL RPC?
[10:40] mikko	https://github.com/zeromq/zfl/blob/master/src/zfl_rpc.c
[10:40] mikko	https://github.com/zeromq/zfl/blob/master/src/zfl_rpcd.c
[10:40] sustrik	you can think of each pattern as a separate protocol on top of basic 0mq framing
[10:40] sustrik	which one are you interested in?
[10:40] kaib	sustrik: pub/sub push/pull req/rep, in that order.
[10:41] kaib	sustrik: we have all those patterns in the system..
[10:41] sustrik	pub/sub and push/pull are easy
[10:41] sustrik	the only specific so far is that the first message sent be each peer is identity
[10:41] sustrik	(see ZMQ_IDENTITY socket option)
[10:42] kaib	sustrik: what does the peer do with the identity?
[10:42] sustrik	if no identity is set, empty message is sent
[10:42] sustrik	it can use when reconnection happens
[10:42] kaib	sustrik: i understood it's used for persisting messages between crashes (presumably somewhere on disk?)
[10:42] sustrik	if the new connection has same identity as one previously broken
[10:42] sustrik	it can reuse the resources allocated for the old one
[10:43] sustrik	so it can hold messages in the memory (or swap them to the disk) while the peer reconnects
[10:44] sustrik	as for REQ/REP see here: http://www.zeromq.org/tutorials:xreq-and-xrep
[10:44] kaib	sustrik: ok, so it's useful for making sure that no messages are dropped even if the client disconnects, right?
[10:45] sustrik	messages can still be lost if they were processed or "on-the-wire" during the failure
[10:45] sustrik	but it makes the whole thing more reliable, yes
[10:45] sustrik	aside of that identities are used for routing replies to the original requesters in REQ/REP pattern
[10:45] sustrik	see the link above
[10:45] sustrik	there's a picture showing how it works
[10:46] sustrik	kaib: btw, why write a new messaging solution?
[10:47] sustrik	i'm not discouraging you, but it takes some manyears to get that done
[10:47] kaib	sustrik: curiosity mostly, partially to see if a native implementation could be better integrated.
[10:48] kaib	sustrik: we run a cluster consisting of ~50 nodes (we are still in pre launch) with the servers all written in Go.
[10:48] kaib	sustrik: i was looking into hooking up mongrel2 as our http server and started reading more about 0mq.
[10:48] sustrik	kaib: sure
[10:49] kaib	sustrik: it seems like pattern used in 0mq is actually quite nice.
[10:49] kaib	sustrik: i've used messaging systems back at Google but never really grokked them, the rpc system is so much more common.
[10:49] sustrik	the patterns are the most interesting part of 0mq i think
[10:50] kaib	sustrik: our main pain point is complexity we run 6 distinct server types with some very complex and latency sensitive interactions.
[10:50] kaib	sustrik: i have a gut feeling that messages might be a good fit, but i need to write some code to make sure that's true.
[10:51] sustrik	give it a try
[10:51] kaib	sustrik: i'm not trying to do a generic library, just something that fits our specific purpose. i'll probably open source it when we have time, but it's definitely just to scratch our own itch.
[10:51] sustrik	well, good luck
[10:51] kaib	sustrik: given the core 0mq library is pretty good .. :-)
[10:52] sustrik	you know, i've seen loads of ad hoc messaging library projects running into troubles
[10:52] sustrik	it looks easy when you start
[10:52] kaib	what type of issues do they usually encounter?
[10:53] sustrik	all kind of asynchronicity issues
[10:53] sustrik	also scaling issues
[10:53] sustrik	everything works ok in test env
[10:53] sustrik	then when you move to production you start to exprience bottlenecks
[10:54] kaib	yep, that seems to be a common pattern for all distributed code.
[10:54] sustrik	later on it turns out that the bottleneck can't be avoided without rewriting the whole code from scratch
[10:54] sustrik	etc.
[10:54] kaib	are the perf problems mostly in userspace or in interactions with the kernel?
[10:54] sustrik	both
[10:56] kaib	i'd love to know more specifics, obviously that's something i'd rather avoid .. are the difficulties related to messaging systems or just concurrent/parallel code in general?
[10:56] kaib	ie. do the people running into trouble have experience with writing distributed systems?
[10:56] sustrik	sure
[11:01] sustrik	for example, there's some 12 manyears altogether spent on 0mq + many more years of messaging experience from beforehand
[11:02] sustrik	but we still run into this kind of trouble occassionally
[11:02] sustrik	say: what happens it 500 peers decide to disconnect at exactly the same moment?
[11:02] sustrik	what's the latency impact for the remaining peers?
[11:03] sustrik	how does the number of cores on the system affect the impact
[11:03] sustrik	etc.
[11:03] sustrik	complex stuff
[11:04] Guthur	sustrik: Sorry I was not watching there
[11:04] Guthur	I was hoping to pick your brains a little regarding the polling classes in 0MQ
[11:04] sustrik	sure
[11:04] sustrik	shoot
[11:05] Guthur	I was investigating in relation to implementing windows named pipes
[11:05] Guthur	is the polling used internally by 0MQ
[11:05] Guthur	and are all the events required?
[11:05] sustrik	what events?
[11:05] Guthur	eg POLLIN, POLLOUT, and POLLERR
[11:06] sustrik	that's used in POSIX poll()
[11:06] sustrik	0mq virtualises the polling mechanism
[11:06] sustrik	and from the user's perspective you have these events:
[11:06] sustrik	in_event
[11:06] sustrik	out_event
[11:07] sustrik	timer_event
[11:07] kaib	sustrik: thanks, i'll tinker around a bit and see what i get. we can always fall back on using the ref implementation if push comes to shove.
[11:07] sustrik	(these are callbacks invoked by the poller class)
[11:07] sustrik	kaib: sure
[11:07] Guthur	ok, sorry I'll be right back
[11:07] Guthur	need to go into a conf call
[11:07] Guthur	sorry about this
[11:09] Guthur	I was checking out select_t, poll_t, epoll_t, devpoll_t and kqueue_t, as you recommended
[11:09] Guthur	is there anywhere else in particular I should look?
[11:10] sustrik	nope, just implement the same interface with IOCP
[11:10] sustrik	ah
[11:11] sustrik	you should also redefine fd_t
[11:11] sustrik	to resolve to HANDLE instead of SOCKET
[11:11] Guthur	Named Pipes in MSWin obviously don't have a poll, all they have is call back functions on completion
[11:11] Guthur	ok
[11:12] sustrik	afaiu you can use ReadFile/WriteFile
[11:12] sustrik	and IOCP for polling
[11:12] sustrik	check that out first though
[11:14] Guthur	yeah ReadFile/WriteFile sync, or ReadFileEx/WriteFileEx async
[11:15] Guthur	each of those accept a completion callback function
[11:15] Guthur	umm I haven't seen this IOCP
[11:15] Guthur	I'll check that out
[13:28] zchrish	Question about exceptions and C++ : When a user gives a bogus hostname, the code asserts. Can I catch the error; what is the accepted alternative to dying in this case?
[13:28] zchrish	This is on a connect.
[13:29] drbobbeaty	You're going to need to check the data before you pass it to zmq. The assert() is not "catchable" like an exception is.
[13:31] zchrish	I see; thank you.
[14:46] ianbarber	pieterh: re DPC talk, will do, I was just waiting to see if i'll be doing it at confoo in canada as well (already speaking there about solr, they asked if I could do another). Not that it takes much longer to update twice
[14:52] ianbarber	i do hope this talk doesn't suck! different sort of audience with PHP devs to your fosdem one, not so much multithreading being discussed :)
[14:56] sustrik	that makes the talk more interesting imo
[17:27] mikko	pieterh: there?
[18:52] Guthur	do we have a way of executing unit tests on the build server?
[18:53] Guthur	or is that outside the remit
[19:13] sustrik	Guthur: make check is executed when zmq is built
[19:14] Guthur	i wonder if I could get something similar set up for clrzmq1
[19:15] Guthur	clrzmq2*
[19:19] Guthur	mikko, you about?
[21:29] CIA-21	jzmq: 03Nathan Marz 07master * r7983d5c 10/ src/Socket.cpp : fix type for args to linger from github issue #26 - http://bit.ly/dWrCkv
[21:29] CIA-21	jzmq: 03Gonzalo Diethelm 07master * r306e3b8 10/ src/Socket.cpp : Arranged proposed changes a bit, and added a cast to avoid a warning. - http://bit.ly/eiciUG