IRC Log

Friday October 15, 2010

[Time] NameMessage
[00:09] un-saad hi folks. quick question: does zeromq support an offline mode?
[00:10] un-saad root question: can it be used to support mostly connected kiosks?
[00:11] un-saad frigg request a CTCP version. they still do that? :)
[04:40] jurgen hello, my name is Jurgen and i have some questions regarding 0mq
[04:41] jurgen who could help me to answer some questions related to 0mq sockets
[04:44] jurgen i have joined using xchat
[04:45] jurgen anyone here to help me a bit on 0mq sockets ?
[05:16] andrewvc yo
[05:16] andrewvc i might be able to help
[05:16] jurgen hi andrew
[05:17] jurgen thanks man, i maybe in a unique time zone here, so i was thinking everyone is asleep
[05:17] jurgen i'm in Shanghai - China
[05:17] jurgen I have a question on how 0MQ is managing it's connections
[05:17] andrewvc oh wow, hehe
[05:17] andrewvc sure
[05:18] jurgen i can explain a bit on the scenario so that you might tell me how 0MQ should be used
[05:18] andrewvc sure
[05:19] jurgen I have implemented a (Symphony) P2P topology using TCP/IP directly
[05:19] jurgen the topology consists of nodes
[05:19] delaney btw, thanks andrewvc for the other day, i grok the general workflow now
[05:19] andrewvc oh sweet
[05:19] jurgen every node has a maximum of around 10 connections
[05:20] andrewvc I'm not familiar with Symphony I should say
[05:20] jurgen and one requirement is that i know which nodes are connecting and disconnecting
[05:20] andrewvc ah
[05:21] andrewvc I see, so you need to really track the state of all nodes, and you don't want ZMQ to delegate requests
[05:21] jurgen with 0MQ i do not seem to find if it can tell which connections cannot be established or have been terminated
[05:21] jurgen i could do it with alive messages
[05:21] andrewvc that's what you'll actually have to do
[05:21] jurgen but that would add traffic
[05:21] andrewvc yep
[05:21] jurgen :-(
[05:22] jurgen bummer
[05:22] andrewvc well
[05:22] andrewvc hmmm
[05:22] andrewvc so, have you looked into the section on routers for xreq/xrep
[05:22] jurgen at what moment does 0MQ actually connect?
[05:22] andrewvc well, in the TCP sense I assume
[05:22] jurgen yes
[05:23] andrewvc as far as I know it connects when you call connect
[05:23] andrewvc but it can reconnect transparently if there's network troubles
[05:23] guido_g hi
[05:23] andrewvc additionally, even if there's nothing to bind to, connect will succeed, and it'll keep retrying to connect till what it's trying to connect to comes up
[05:23] jurgen hmmm, so if in some way 0mq could tell me the status of the connection
[05:23] guido_g connect will return before the connection is established
[05:24] jurgen yes, it is as far as i know a delayed connect
[05:24] guido_g exactly
[05:24] jurgen thanks guido
[05:24] guido_g you don't know if and when ømq tries to do the actual connect
[05:24] jurgen and that brings me to the other point is, that there is no 'disconnect'
[05:24] guido_g same for close/shutdown
[05:25] guido_g you've to close the whole ømq socket
[05:25] delaney no, they expect you'll hanlde it at the app layer basically from what i've seen
[05:25] andrewvc yes
[05:25] jurgen personally i really love the setup of 0mq
[05:25] delaney there is a high water mark per socket connection so if you hit that then it drops
[05:26] jurgen i think i will dive into it and see how to add disconnect and a status retrieval
[05:26] guido_g delaney__: or blocks, depends on socket type
[05:26] delaney right, i meant with xrep
[05:26] guido_g jurgen_: if you will get this through, i owe you a beer or three :)
[05:26] delaney jurgen_ i've been asking the same questions for my project
[05:27] jurgen hey guido, where are you located ?
[05:27] jurgen Belgium ?
[05:27] guido_g nope
[05:27] guido_g hamburg
[05:27] guido_g germany
[05:27] jurgen Ah, german beer
[05:27] jurgen sounds good
[05:27] andrewvc btw, jurgen__, have you read the guide section on routers/dealers?
[05:27] jurgen yes, i have read it yesterday and this morning
[05:27] andrewvc ah, cool
[05:28] jurgen i wouldn't say i completely see the light
[05:29] guido_g it takes a while to adjust to the ømq way of thinking
[05:29] jurgen but i get a sense of what it does
[05:29] guido_g problem is, if you've done networkprogramming before, it's in the way a bit
[05:29] jurgen the thing is that my topology is dynamic, nodes come and go
[05:29] jurgen i have done network programming now for 4 weeks :-)
[05:30] guido_g this is a known limitation of ømq, you don't know which node is connected to a socket
[05:30] jurgen but i am in the Game Industry for 11 years
[05:30] guido_g gaming
[05:30] guido_g here is another guy doing gaming with ømq
[05:31] jurgen yeah, C++ software engineer
[05:31] guido_g i mean here in the channel
[05:31] delaney well i'm a game guy
[05:31] jurgen i am trying to create a P2P topology
[05:31] andrewvc correct me if I'm wrong, but isn't the router/dealer topology there for situations where you need explicit routing control and knowledge of the aliveness of connected stuff
[05:31] guido_g i'd p2p is not the best use-case for ømq
[05:31] guido_g *i'd say
[05:31] jurgen to andrewvc: yes, the router/dealer is for a known topology
[05:31] delaney yep... we already have a xreq/xrep setup working andrewvc with c++ clients and python backend
[05:32] jurgen to andrewvc: as far as i understand it
[05:32] guido_g andrewvc: no, because you don't know if a node is connected to a socket at the moment or not
[05:32] delaney actually jurgen_ router/dealer is working for our game
[05:32] andrewvc well, yes, but you can build that on top I meant
[05:32] delaney cause its bi-directional and we already have timeout for sockets that don't send a message in a given time
[05:32] guido_g sure, but it'll be clumsy
[05:32] andrewvc and then only route to stuff you know exists. But then you're kinda reimplementing a lot of TCP stuff (keep alive for instance)
[05:33] guido_g right
[05:33] jurgen for the p2p topology i need a messaging layer + a seed/leech layer (heavy upload/download traffic, using UDT library)
[05:33] guido_g but if enough people request this feature it might appear in the future
[05:33] delaney heh, was asking about UDP yesterday :P
[05:34] jurgen 0mq is offering so much more, inter-process, multi theading etc... it is hard to not use it
[05:34] guido_g delaney__: unicast-udp?
[05:34] guido_g delaney__: may i ask what your use-case is?
[05:34] jurgen UDT = http://udt.sourceforge.net/
[05:34] delaney its wasn't my use case, its was an rts
[05:35] guido_g ahh i see
[05:35] jurgen This is what i have build with simple TCP/IP: http://ast-deim.urv.cat/wiki/Symphony
[05:35] delaney ours is a turn based that looks real time, so its tcp was hopefully 1000s of games going on a single box (but zeromq makes scaling a probabilty to multiple machines)
[05:36] delaney well jurgen_ before you get UDT zmq needs to do UDP it looks like
[05:37] jurgen not really
[05:37] jurgen the p2p topology can be done with simple messaging
[05:38] jurgen the upload/download between nodes of files is the second purpose, for this i need fast upload/download speed, that is where UDT can help
[05:39] guido_g hmmm... seems that tcp isn't the best choice for p2p
[05:39] guido_g lots of connections
[05:41] jurgen when the topology changes (1 or more nodes leave/join) then some connections get dropped and some get established
[05:41] jurgen it is actually not a lot of connections that are cut/dropped
[05:42] guido_g i meant active connections, from each node to a lot of other nodes
[05:42] guido_g not the best case for tcp
[05:44] delaney i don't know WOW works completely on tcp and they have quite a few people connected all the tim e
[05:45] guido_g sure, you can handle a few thousand tcp connections doing approx. 4kb/sec on one large box
[05:45] jurgen the overhead is in creating and destroying a TCP/IP connection
[05:45] guido_g but thinking about p2p it'S going to work
[05:45] delaney ah, good point
[05:45] guido_g *it's not going to work
[05:46] delaney so would pub/sub work for him?
[05:46] jurgen my scenerio is limited to a max of 512 nodes
[05:46] guido_g think alone of incomming connections and packet filters
[05:46] delaney and then a req/rep whn you see something you want?
[05:46] guido_g delaney__: youn still need a connection to the node
[05:47] delaney so multicast?
[05:47] guido_g this will over time connect to a high number of nodes
[05:47] jurgen every node has an average of 10 connections
[05:47] guido_g multicast doesn't work on the internet
[05:47] delaney for 10 tcp is fine no?
[05:47] guido_g if the firewall permits it
[05:48] jurgen is it possible to drop images here in XChat ?
[05:48] guido_g no
[05:48] guido_g irc is text only
[05:49] delaney you can use imageshack or something
[05:50] guido_g problem i see with p2p using tcp is that connections from the outside need to be allowed
[05:50] guido_g packet filters will go berserk if you try this
[05:51] guido_g beeing p2p you can't even allow an ip or ip range to connect, because the ips are basically random
[05:51] delaney what are you suggesting then for his case?
[05:52] guido_g either a more centralized architecture
[05:52] guido_g using only outgoing connections for the nodes
[05:52] guido_g (the game clients i assume)
[05:52] guido_g urgs...
[05:52] jurgen well it is not for a game
[05:52] guido_g there is no other solution
[05:52] jurgen :-)
[05:53] guido_g ahhh, but for clients on the internet, not on a controlled network?
[05:55] jurgen I am trying to build this (slurpie, slurpie.sourceforge.net) but using Symphony as the topology
[05:55] guido_g with udp you could do the skype trick to foole most packet filters http://www.h-online.com/security/features/How-Skype-Co-get-round-firewalls-747197.html
[05:56] guido_g why not one of the open source p2p protocols?
[06:06] jurgen here is a screenshot of a Symphony topology: http://picasaweb.google.com/100898468756478508796
[06:07] jurgen this is from my C# application simulating N number of nodes, you can add and remove nodes dynamically
[06:08] jurgen last week i finished my prototype in C++ with boost and UDT (UDP library) and it is working
[06:08] jurgen but it is very rough
[06:08] jurgen ok, thanks so far for your help guys, i will dig into 0MQ and see if i can add stuff
[06:09] guido_g good luck then
[06:09] jurgen maybe even UDP/UDT, but first i want to see if i can add disconnect/status on a socket
[06:10] guido_g would be great :)
[06:12] jurgen thanks
[08:19] sustrik does anyone have experience with UDT here?
[08:20] sustrik i keep bumping into it occasionally
[08:20] sustrik would it make a good transport for 0mq?
[08:24] mikko good morning
[08:25] mikko sustrik: based on the description it looks interesting
[08:25] sustrik it's there for several years
[08:25] mikko BSD license as well
[08:25] sustrik looks like a quite stable project
[08:26] sustrik transport for high-bandwidtgh, high-latency links
[08:26] sustrik satelite links etc.
[08:26] sustrik it would be good to speak to someone who actually used it
[08:26] mikko http://sourceforge.net/projects/udt/forums
[08:26] mikko ?
[08:27] sustrik :)
[08:27] sustrik right
[08:27] sustrik mikko: the fix, will you chenge the casts, or should I?
[08:27] mikko sustrik: i can change
[08:27] mikko icc also gives tons of remarks
[08:27] sustrik ok, i'll commit the other two patches in the meantime
[08:28] mikko it seems to be a lot more verbose than gcc
[08:28] sustrik can you upload it somewhere?
[08:28] sustrik gist?
[08:28] sustrik or is it part of hudson already?
[08:28] sustrik seen the icc license btw?
[08:29] mikko i just read their 'non-commercial' FAQ
[08:29] mikko not the full license
[08:29] sustrik they've gave us full license
[08:29] sustrik sent it yesterday
[08:30] mikko ah, i have no internet at home and haven't made that far in email backlog
[08:30] mikko i'll add the build to hudson
[08:30] sustrik ok, you have it in your mailbox
[08:38] CIA-14 zeromq2: 03Mikko Koppanen 07master * re33e4d7 10/ (AUTHORS src/pipe.hpp):
[08:38] CIA-14 zeromq2: ICC related qualifier fix
[08:38] CIA-14 zeromq2: Signed-off-by: Mikko Koppanen <mkoppanen@php.net> - http://bit.ly/d6aafo
[08:41] mikko sustrik: should i change just the local timeout to be int rather than the method signature?
[08:41] mikko it seems that same pattern is present devpoll, kqueue and select as well
[08:42] sustrik just local timeout
[08:42] sustrik if possible, fix all of them (where applicable):
[08:42] sustrik select
[08:42] sustrik poll
[08:42] sustrik epoll
[08:42] sustrik devpoll
[08:42] sustrik kqueue
[08:43] CIA-14 zeromq2: 03Mikko Koppanen 07master * re288f7a 10/ configure.in :
[08:43] CIA-14 zeromq2: Fixes build on Linux using Sun Studio compiler
[08:43] CIA-14 zeromq2: Signed-off-by: Mikko Koppanen <mkoppanen@php.net> - http://bit.ly/aNALk2
[08:43] mikko what's preferred cpp cast? static_cast<int> or (int) ?
[08:44] sustrik i'm using (int)
[08:44] sustrik it's shorter :)
[08:47] mikko http://valokuva.org:8080/job/ZeroMQ2_master_ICC/1/console
[08:47] mikko let me prepare the patch
[08:51] sustrik nice, /me is checking the output
[08:59] CIA-14 zeromq2: 03Martin Sustrik 07master * rb64b50a 10/ (src/pgm_receiver.cpp src/pgm_sender.cpp src/pgm_sender.hpp):
[08:59] CIA-14 zeromq2: Timers correctly canceled by PGM engines on shutdown.
[08:59] CIA-14 zeromq2: Signed-off-by: Martin Sustrik <sustrik@250bpm.com> - http://bit.ly/cVEmQ5
[09:22] CIA-14 zeromq2: 03Mikko Koppanen 07master * r3e74a43 10/ (5 files):
[09:22] CIA-14 zeromq2: Cast execute_timers() result to int
[09:22] CIA-14 zeromq2: Signed-off-by: Mikko Koppanen <mkoppanen@php.net> - http://bit.ly/aAk4P8
[09:25] mikko sustrik: http://valokuva.org:8080/job/ZeroMQ2_master_ICC/4/console
[09:25] mikko should build now
[09:33] CIA-14 zeromq2: 03Martin Sustrik 07master * r17b0785 10/ src/poller_base.hpp :
[09:33] CIA-14 zeromq2: Destructor of poller_base_t made virtual.
[09:33] CIA-14 zeromq2: Signed-off-by: Martin Sustrik <sustrik@250bpm.com> - http://bit.ly/a60xaJ
[09:33] CIA-14 zeromq2: 03Martin Sustrik 07master * r7b9e397 10/ src/devpoll.hpp :
[09:33] CIA-14 zeromq2: Minor fix in devpoll.hpp
[09:33] CIA-14 zeromq2: Signed-off-by: Martin Sustrik <sustrik@250bpm.com> - http://bit.ly/9b5d7X
[09:36] sustrik mikko: nice
[09:36] sustrik i'll try to get rid of at least some of the warnings
[09:39] mikko ill get on with the -pedantic
[09:39] mikko at some point
[11:49] mikko autotools are such a joy
[11:51] sustrik :)
[11:53] sustrik mikko: btw, what about announcing the build dev publicly?
[11:54] sustrik build env
[12:04] mikko sustrik: yeah, it seems fairly stable at the moment. hopefully the server can handle the load if all lurkers from the list rush in
[12:05] sustrik let's try it then
[12:05] sustrik presumably a link from zeromq.org & an announcement link
[12:06] sustrik btw, you may also consider doing some self-promotion on the build env site
[12:07] sustrik "this build env is brought to you by mikko koppanen!"
[12:07] mikko sent mail to list for checking icc during configure stage
[12:07] mikko i gotta eat as well brb
[12:08] sustrik cya
[12:41] mato sustrik: for 2.0.10... i have a bit of time today (leaving the refactoring work i'm doing to sleep in the back of my head)
[12:41] mato sustrik: so, what i want to do is clear up the version stuff, and my patch for DSO visibility
[12:42] mato sustrik: once we have those two changes reviewed and applied, and tested at least on a couple systems we could then make a 2.0.10 ASAP next week
[12:42] sustrik mato: OK
[12:44] sustrik however, think about whether it makes sense to add the visibility stuff to maint
[12:44] sustrik it's not really a bugfix
[12:44] sustrik rather a new feature
[12:45] mato well, one could argue that the rampant dynamic symbol table pollution is a bug :-)
[12:45] sustrik it's up to you
[12:45] mato and anyhow, ZMQ_VERSION is also a "new feature" :-)
[12:46] sustrik but useless wthout being in both maint and master
[12:48] sustrik mato, all: question
[12:48] sustrik what's the sane default for linger option?
[12:48] sustrik infinite mimics TCP
[12:48] sustrik 0 mimics 0MQ/2.0.x
[12:48] mato sustrik: this and the entire semantics should be written up and discussed on email
[12:49] mato sustrik: not here, it's out of context...
[12:49] sustrik ok, i'll go with infinite for now
[13:40] sustrik mato: thanks
[13:40] sustrik can you check mikko's patch btw?
[13:40] mato sustrik: was going to get around to that; i presume you're applying all these "build with X compiler" fixes only to master on purpose, yes?
[13:41] sustrik yes
[13:44] mato ok
[13:44] mato are you happy with my changes to the version stuff?
[13:45] sustrik looks good
[13:46] sustrik but i trust you :)
[13:47] sustrik what about those tools used to dissect the version numbers?
[13:47] sustrik are they likely to be available on all systems?
[13:49] mato egrep and awk? yes, of course
[13:49] mato i guess i can test on solaris just to make sure it's egrep is not funny or something
[13:49] mato tried freebsd, that works fine
[13:49] sustrik ack
[13:49] mato in any case, those are only needed by people running autogen.sh
[13:49] sustrik sure
[13:50] sustrik what about the application of patches
[13:50] sustrik it's both maint and master, right?
[13:50] mikko mato: isn't there autoconf checks for those?
[13:50] mikko AC_PROG_EGREP
[13:50] mikko etc
[13:51] mato mikko: yes, but they won;t help
[13:51] mato mikko: since this is used to *generate* configure
[13:51] mato mikko: also, what UNIX doesn't have egrep/awk?
[13:52] mato sustrik: both, yes, let me just test solaris to be 100% sure
[13:52] sustrik ok
[13:53] mikko hmm
[13:53] mikko i could add solaris build box later
[13:53] mikko it runs on x86
[13:54] sustrik the build env is on the brink of becoming self-conscious :)
[14:09] rphillips I need some advice regarding zmq. I have a subscriber to a pub/sub, and would like to loadbalance the messages received to worker threads. I'm using a PUSH/PULL inproc socket to load balance to the threads.
[14:10] rphillips this means there is only one loop reading from the subscriber socket
[14:10] rphillips is there a way I can read multiple messages from the subscriber socket and push to the threads?
[14:11] mikko interesting 2 of 7 tests failed
[14:11] mikko with sun studio
[14:12] mikko rphillips: call zmq_recv multiple times?
[14:14] sustrik mikko: strange
[14:15] sustrik maybe ipc?
[14:16] sustrik no, it's still linux
[14:16] sustrik should be the same
[14:16] mikko there are clang builds as well
[14:17] mato sustrik: ok, solaris 2.0.10 build and autogen.sh seem to work
[14:17] mato sustrik: so i'd say please apply my patches, that's if you're happy with the cleanup/move of the version macros I did
[14:19] sustrik sure
[14:19] sustrik what's clang?
[14:20] ptrb c/c++ frontend to llvm
[14:20] mato sustrik: ok, so i reckon i'd leave the dso visibility changes out of maint, after all, no one has complained about that
[14:21] sustrik exactly
[14:21] mato sustrik: one last thing i would like to do is bump OpenPGM on maint to the 2.1.28
[14:21] sustrik don't fix it if it ain't broken
[14:21] sustrik mato: why so?
[14:21] mato sustrik: this is so that I can use the DFSG-free tarball, which means I can simplify the debian packaging process muchly
[14:21] sustrik ok, np
[14:21] mato sustrik: ... there was a thread on the ML about this some time ago ...
[14:21] sustrik yes, i recall
[14:28] sustrik mato: how can I apply the patch?
[14:29] sustrik can you send it as an attachment?
[14:29] mato sustrik: huh?
[14:29] mato oh, right, your crap mail client
[14:29] sustrik :(
[14:29] sustrik send it directly to me
[14:31] mato sent
[14:41] mato sustrik: ok, so, I've grabbed Steve's OpenPGM 2.1.28~dfsg tarball, integrated it into 2.0.10, builds on Linux/amd64
[14:41] mato canonical test (i.e. zmq-camera) seems to work
[14:41] mato sustrik: However, this means replacing the binary tarball... it doesn't make sense (and is probably not even possible) to send that as a patch
[14:41] mato sustrik: Can I push the commit to 'maint', and you will do the rest? (just merge 2.1 and squash the changes, as usual)
[14:44] askingq anyone here?
[14:45] askingq does zeromq store locally if its disconnected?
[14:46] mato askingq: no on-disk persistence; messages will be queued in-memory for some socket types (e.g. REQ/REP)
[14:47] askingq mato: our systems may be disconnected for days. is there a plan to support local persistence?
[14:48] sustrik mato: what's this:
[14:48] sustrik git am 0001-configure.in-Extract-API-version-from-zmq.h.patch
[14:48] sustrik previous rebase directory /home/sustrik/zeromq2-maintainer/.git/rebase-apply still exists but mbox given.
[14:48] mato sustrik: bah, I don't know
[14:48] sustrik :)
[14:49] mato I've not really tested git-am in any way
[14:50] mato askingq: not that I know of, but a rabbitmq-zeromq bridge is available which may be useful for your use case
[14:54] mato sustrik: google seems to say, just remove that file
[14:54] mato sustrik: did git-am actually apply anything?
[14:54] sustrik mato: i've done everything from beginning and now it works
[14:54] mato sustrik: so you just ran "git am" on the two patches i sent you?
[14:54] sustrik yes
[14:54] mato and it worked?
[14:55] sustrik yes
[14:55] mato great!
[14:58] CIA-14 zeromq2: 03Martin Lucina 07maint * r3b3df73 10/ (Makefile.am configure.in include/zmq.h version.sh): (log message trimmed)
[14:58] CIA-14 zeromq2: configure.in: Extract API version from zmq.h
[14:58] CIA-14 zeromq2: * Added a version.sh and relevant changes to configure.in to extract the API
[14:58] CIA-14 zeromq2: version from zmq.h at the time autogen.sh is run.
[14:58] CIA-14 zeromq2: * Moved the version macros to be next to zmq_version in zmq.h and improved
[14:58] CIA-14 zeromq2: the comments.
[14:58] CIA-14 zeromq2: * Modified ZMQ_MAKE_VERSION to use (x) instead of plain x when expanding
[14:58] CIA-14 zeromq2: 03Martin Lucina 07maint * r3cf01bf 10/ Makefile.am :
[14:58] CIA-14 zeromq2: Makefile.am: Add missing files to distribution, improve maintainer-clean
[14:58] CIA-14 zeromq2: Add missing files needed for regenerating configure to the distribution;
[14:58] CIA-14 zeromq2: add MAINTAINERS; improve maintainer-clean to produce a really clean tree.
[14:58] CIA-14 zeromq2: Signed-off-by: Martin Lucina <mato@kotelna.sk> - http://bit.ly/9TmEGj
[14:59] mikko sustrik: remote_lat.exe: ** (remote_lat/bin/Debug/remote_lat.exe:9433): WARNING **: Shutting down finalizer thread timed out.
[15:00] sustrik mikko: that's java or what?
[15:01] mato .exe == Mono
[15:01] sustrik hm, obviously the linger issue
[15:01] sustrik what's the command line?
[15:01] sustrik message size, message count
[15:02] mikko 100 100
[15:02] sustrik that's nothing
[15:03] mato sustrik: what about that openpgm change? I need to wait until you are done applying patches if I'm to push that
[15:03] mato sustrik: so that I don't step on your toes...
[15:03] sustrik wiat a sec!
[15:03] mato 1.. 2..
[15:03] mato :-)
[15:04] sustrik attempt to merge to master:
[15:04] sustrik ./configure
[15:04] sustrik ./configure: line 2539: zeromq-dev@lists.zeromq.org: No such file or directory
[15:04] sustrik ./configure: line 2540: _ACEOF: command not found
[15:04] sustrik ./configure: line 2542: syntax error near unexpected token `fi'
[15:04] sustrik ./configure: line 2542: `fi'
[15:05] mato huh?
[15:05] sustrik that's what confiugre says
[15:06] mato yes, what did you do when merging?
[15:06] mato did you have to resolve conflicts?
[15:06] sustrik yes
[15:06] sustrik zmq.h
[15:06] mato what do the relevant lines in configure.in (the AC_INIT stuff) look like?
[15:07] sustrik there's a conflict i haven't spotted
[15:07] sustrik sorry
[15:07] mato double-check what goes on master
[15:08] mato it should be exactly the same as on maint, except for the version number, obviously
[15:13] sustrik mato: what options to git commit should i use after i've merged the conflicts?
[15:13] mato sustrik: dunno, just -s I guess to sign it off as yourself
[15:13] sustrik ok
[15:15] CIA-14 zeromq2: 03Martin Lucina 07master * r3b3df73 10/ (Makefile.am configure.in include/zmq.h version.sh): (log message trimmed)
[15:15] CIA-14 zeromq2: configure.in: Extract API version from zmq.h
[15:15] CIA-14 zeromq2: * Added a version.sh and relevant changes to configure.in to extract the API
[15:15] CIA-14 zeromq2: version from zmq.h at the time autogen.sh is run.
[15:15] CIA-14 zeromq2: * Moved the version macros to be next to zmq_version in zmq.h and improved
[15:15] CIA-14 zeromq2: the comments.
[15:15] CIA-14 zeromq2: * Modified ZMQ_MAKE_VERSION to use (x) instead of plain x when expanding
[15:15] CIA-14 zeromq2: 03Martin Lucina 07master * r3cf01bf 10/ Makefile.am :
[15:15] CIA-14 zeromq2: Makefile.am: Add missing files to distribution, improve maintainer-clean
[15:15] CIA-14 zeromq2: Add missing files needed for regenerating configure to the distribution;
[15:15] CIA-14 zeromq2: add MAINTAINERS; improve maintainer-clean to produce a really clean tree.
[15:15] CIA-14 zeromq2: Signed-off-by: Martin Lucina <mato@kotelna.sk> - http://bit.ly/9TmEGj
[15:15] CIA-14 zeromq2: 03Martin Sustrik 07master * reeb8e7c 10/ (Makefile.am configure.in include/zmq.h version.sh): (log message trimmed)
[15:15] CIA-14 zeromq2: Merge branch 'maint'
[15:15] CIA-14 zeromq2: * maint:
[15:15] sustrik mato: done
[15:15] mato sustrik: let me double-check it all
[15:20] sustrik intersting, it looks like inproc transport doesn't work when 0mq is compiled with sun studio
[15:20] sustrik clang! it's there!
[15:20] sustrik :)
[15:24] mikko yes
[15:24] mikko and seems to build as well
[15:25] mato sustrik: ok, all seems fine
[15:25] mato sustrik: so, can I do the push and merge for OpenPGM?
[15:26] sustrik good, i'll apply taras' patch now
[15:26] mato ah, ok
[15:26] sustrik it should not conflict
[15:26] sustrik go on
[15:26] mato hang on
[15:26] mato well
[15:26] mato yes
[15:26] mato but it'll be nicer if we work in lock-step
[15:26] sustrik ok, go on
[15:26] mato no silly extra merge commits
[15:26] sustrik i'll apply it afterwards
[15:26] mato ok, give me a minute
[15:30] sustrik CI?
[15:31] CIA-14 zeromq2: 03Martin Lucina 07maint * r5b44025 10/ (3 files in 2 dirs):
[15:31] CIA-14 zeromq2: maint: Upgrade OpenPGM to 2.1.28~dfsg
[15:31] CIA-14 zeromq2: Upgrade OpenPGM to version 2.1.28 for ZeroMQ 2.0.x. Now we also use the
[15:31] CIA-14 zeromq2: DFSG-compliant upstream release tarball.
[15:31] CIA-14 zeromq2: Signed-off-by: Martin Lucina <mato@kotelna.sk> - http://bit.ly/aOYQ0x
[15:31] mikko continuous integration
[15:31] CIA-14 zeromq2: 03Martin Lucina 07master * r5b44025 10/ (3 files in 2 dirs):
[15:31] CIA-14 zeromq2: maint: Upgrade OpenPGM to 2.1.28~dfsg
[15:31] CIA-14 zeromq2: Upgrade OpenPGM to version 2.1.28 for ZeroMQ 2.0.x. Now we also use the
[15:31] CIA-14 zeromq2: DFSG-compliant upstream release tarball.
[15:31] CIA-14 zeromq2: Signed-off-by: Martin Lucina <mato@kotelna.sk> - http://bit.ly/aOYQ0x
[15:31] CIA-14 zeromq2: 03Martin Lucina 07master * r2e9871c 10/ :
[15:31] CIA-14 zeromq2: Merge branch 'maint'
[15:31] CIA-14 zeromq2: Conflicts:
[15:31] CIA-14 zeromq2: configure.in
[15:31] CIA-14 zeromq2: Signed-off-by: Martin Lucina <mato@kotelna.sk> - http://bit.ly/ajw5kg
[15:31] sustrik :(
[15:32] mato sustrik: done
[15:32] sustrik mato: there was OpenPGM/5 in the master
[15:32] mato sustrik: the CIA messages are misleading
[15:32] mato sustrik: anyway, it's a merge of the commit, otherwise the workflow breaks, but the actual commit is empty
[15:33] sustrik ok, i see
[15:33] mato sustrik: I guess I should have put a clear comment to that effect in the merge commit
[15:33] sustrik np, it just scared me
[15:33] sustrik can i go on now?
[15:33] mato anyway, if you verify with e.g. gitk --all after pulling both branches you'll see that all is as it should be
[15:33] mato just the history is a bit confusing
[15:33] mato yeah, go on
[15:36] mato sustrik: anyhow, from my point of view i think this means we're clear for a 2.0.10 release
[15:36] sustrik ack
[15:36] sustrik just let me apply taras' patch
[15:37] sustrik it's a leak that exists in maint as well
[15:46] CIA-14 zeromq2: 03Taras Shpot 07maint * r6e95205 10/ (AUTHORS src/uuid.cpp src/uuid.hpp): (log message trimmed)
[15:46] CIA-14 zeromq2: Fix memory leak under Windows
[15:46] CIA-14 zeromq2: The comment about memory ownership in uuid_t::to_string
[15:46] CIA-14 zeromq2: was misleading as on most platforms the buffer is a field
[15:46] CIA-14 zeromq2: of the object;
[15:46] CIA-14 zeromq2: The string allocated in UuidToString() wasn't properly freed
[15:46] CIA-14 zeromq2: with RpcStringFree()
[15:48] mikko mato: https://gist.github.com/c4b0a466351af5ceeddd
[15:48] mikko after make dist
[15:50] CIA-14 zeromq2: 03Taras Shpot 07master * r6e95205 10/ (AUTHORS src/uuid.cpp src/uuid.hpp): (log message trimmed)
[15:50] CIA-14 zeromq2: Fix memory leak under Windows
[15:50] CIA-14 zeromq2: The comment about memory ownership in uuid_t::to_string
[15:50] CIA-14 zeromq2: was misleading as on most platforms the buffer is a field
[15:50] CIA-14 zeromq2: of the object;
[15:50] CIA-14 zeromq2: The string allocated in UuidToString() wasn't properly freed
[15:50] CIA-14 zeromq2: with RpcStringFree()
[15:50] CIA-14 zeromq2: 03Martin Sustrik 07master * r027eed4 10/ (AUTHORS src/uuid.cpp src/uuid.hpp):
[15:50] CIA-14 zeromq2: Merge branch 'maint'
[15:50] CIA-14 zeromq2: * maint:
[15:50] CIA-14 zeromq2: Fix memory leak under Windows - http://bit.ly/9VEhl7
[15:51] sustrik mato: ok, done
[16:04] sustrik mato: summon
[16:12] mato sustrik: ja? sorry, got distracted...
[16:12] mato mikko: looks good then
[16:12] mikko apart from the whitespace
[16:12] mikko two whitespaces at end of lines
[16:13] mikko git makes quite a noise out of those
[16:13] mato yeah, but at least that means extraneous whitespace changes can be squashed
[16:13] mato e.g. people with editors that do/don't expand tabs, etc
[16:14] mato sustrik: what's up? I'm kind of done for today, want to get out of here...
[16:33] travlr zeromq2: Martin Sustrik master * r027eed4 / (AUTHORS src/uuid.cpp src/uuid.hpp):
[16:33] travlr sorry... disregard
[17:39] CIA-14 zeromq2: 03Martin Sustrik 07master * r53d1677 10/ NEWS :
[17:39] CIA-14 zeromq2: Update NEWS for 2.0.10 release
[17:39] CIA-14 zeromq2: Signed-off-by: Martin Sustrik <sustrik@250bpm.com> - http://bit.ly/dme9v1
[17:39] CIA-14 zeromq2: 03Martin Sustrik 07master * r18d46c8 10/ NEWS : Merge branch 'maint' - http://bit.ly/dcfXVM
[17:39] CIA-14 zeromq2: 03Martin Sustrik 07maint * r53d1677 10/ NEWS :
[17:39] CIA-14 zeromq2: Update NEWS for 2.0.10 release
[17:39] CIA-14 zeromq2: Signed-off-by: Martin Sustrik <sustrik@250bpm.com> - http://bit.ly/dme9v1
[17:56] athomas hello
[17:59] aat hello
[18:01] aat i've got a full mesh topology with transient clients needing to send directly to each other; what would be the best zmq topology to achieve something like this?
[18:01] aat i've tried a few different approaches, but without much luck
[18:07] aat i should say peers rather than clients
[18:07] cremes aat: is there any pattern to their communications?
[18:07] cremes e.g. pub/sub, req/rep, etc?
[18:09] aat not that i can see; it aligns very closely with a traditional socket pattern of accepting, starting a new handler for that connection that holds state for the duration and tears down when the client disconnects
[18:09] aat which i can't match to any of the zmq socket types
[18:09] aat but it may be that i just haven't fully grokked zmq yet :)
[18:11] aat the closest i can think of is having each peer listen on a REP socket. all peers set their socket identities. each peer routes messages to the appropriate handler based on identity
[18:12] aat if that's possible
[18:14] rphillips aat: you can pass the endpoint in a frame within zmq
[18:15] rphillips that way whomever receives the message(s) knows where to send a response, if applicable
[18:15] cremes aat: yeah... that's the only one that comes to mind too
[18:16] cremes it's kind of a bastardization of xrep/xreq to do that kind of pinpoint routing, but it is doable
[18:16] aat rphillips: okay, thanks. i will give that a try
[18:16] cremes for debugging purposes, you'll probably want to put a "queue" device in between all peers
[18:17] aat ah ok
[18:17] aat why's that exactly?
[18:17] cremes that device (well, a small modification of the stadard one) could print the routing data as it comes through
[18:17] cremes it helps immensely with debugging, that's all
[18:17] cremes well, it has one more benefit
[18:17] aat ok
[18:17] cremes you can avoid sending endpoints in your messages because everything will *connect* to the same device
[18:18] cremes it becomes a well-known service in your topology
[18:18] cremes does that make sense?
[18:18] aat yes it does
[18:18] rphillips cremes: how does the device distinguish where to route the request?
[18:20] aat one other question while i'm here. how efficient is the PUB/SUB system? as in, if i have 10 clients connected, but subscribed to different topics, will packets still be delivered to all clients? ie. is the topic filtering done on the client?
[18:20] aat if using tcp i eman
[18:20] aat mean
[18:21] aat "will packets for all topics be delivered to all clients" i mean (sorry, late here)
[18:22] cremes rphillips: the routing is inherent to the 0mq library; it reads the routing info off the front of each message and uses it to route the data to the correct recipient
[18:22] cremes aat: all packets are delivered to all subscribers because the subscribers do the filtering
[18:22] cremes there has been quite a bit of discussion about moving that filtering operation to the publisher
[18:23] aat ok cool, good to know
[18:23] cremes i recommend searching the ML archives for those past discussions
[18:23] aat ok
[18:23] cremes last i heard, the 0mq folks were waiting for a paying customer to step up and sponsor it because it was rather complex to solve
[18:28] aat kk, thanks guys
[22:48] CIA-14 zeromq2: 03Martin Sustrik 07maint * r710615c 10/ include/zmq.h :
[22:48] CIA-14 zeromq2: Version number increased.
[22:48] CIA-14 zeromq2: Signed-off-by: Martin Sustrik <sustrik@250bpm.com> - http://bit.ly/bxuT2d
[22:49] CIA-14 zeromq2: 03Martin Sustrik 07master * r710615c 10/ include/zmq.h :
[22:49] CIA-14 zeromq2: Version number increased.
[22:49] CIA-14 zeromq2: Signed-off-by: Martin Sustrik <sustrik@250bpm.com> - http://bit.ly/bxuT2d
[22:49] CIA-14 zeromq2: 03Martin Sustrik 07master * rae5a3c8 10/ :
[22:49] CIA-14 zeromq2: Merge branch 'maint'
[22:49] CIA-14 zeromq2: * maint:
[22:49] CIA-14 zeromq2: Version number increased.
[22:49] CIA-14 zeromq2: Conflicts:
[22:49] CIA-14 zeromq2: include/zmq.h
[22:49] CIA-14 zeromq2: Signed-off-by: Martin Sustrik <sustrik@250bpm.com> - http://bit.ly/9SYsYE
[22:57] travlr sustrik: hi martin are you around?
[22:59] sustrik travlr_: hi
[22:59] travlr hi
[23:00] travlr ...
[23:00] travlr i'm just wondering why you push immediately after pushing to master... why more than once?
[23:01] sustrik the first was push to maint
[23:01] sustrik the second is master
[23:02] travlr and the third was to merge maint to master... can you do that locally by any chance?
[23:02] sustrik i don't think so
[23:02] sustrik merging is a full-blown commit
[23:03] travlr I think you can and it will show the commit just as it would the way you are doing it now.
[23:04] sustrik what's your idea?
[23:04] travlr well it's causing a problem with my zmqircd daemon that needs fixing...
[23:04] travlr i just haven't had the time to do it
[23:05] travlr so i thought you might correct it for me if you can by commiting less often
[23:05] travlr ...not immediately
[23:05] travlr one after another
[23:06] sustrik the point is that if i'm doing a change to maint that needs to be propagated to master
[23:06] sustrik there have to be 3 separate commits
[23:06] sustrik 1. update to maint
[23:06] sustrik 2. update to master
[23:06] sustrik 3. merge
[23:07] travlr can you do...
[23:07] travlr 1. update maint
[23:07] travlr 2. merge maint to master locally
[23:07] travlr 3. push master
[23:07] travlr ?
[23:08] sustrik maint is a public repo (2.0.x family of versions)
[23:08] sustrik it has to go to github
[23:08] travlr yes i know
[23:08] travlr 1. push updated maint to repo
[23:08] travlr 2. merge maint to master locally
[23:08] travlr 3. push already merge master to repo
[23:09] sustrik that's what i am doing
[23:09] travlr no, i think you push to master and merge remotely instead of doing first locally
[23:10] sustrik no, the sequence goes like this:
[23:10] sustrik git checkout master
[23:10] sustrik git merge maint
[23:10] sustrik git push origin master
[23:11] travlr hmm.. i see
[23:11] sustrik what's the problem with irc daemon?
[23:11] travlr must have to do with automatic remote refs then
[23:11] travlr i'm using an irclib that is single threaded... i have to fix that
[23:12] travlr causes problems sometimes... no big deal
[23:12] travlr thanks
[23:12] sustrik np
[23:13] CIA-14 zeromq2: 03Martin Sustrik 07master * r48b0a90 10/ src/config.hpp :
[23:13] CIA-14 zeromq2: Obsolete compile-time option removed.
[23:13] CIA-14 zeromq2: Signed-off-by: Martin Sustrik <sustrik@250bpm.com> - http://bit.ly/99Gpx5
[23:13] CIA-14 zeromq2: 03Mikko Koppanen 07master * rb95f11a 10/ (configure.in acinclude.m4):
[23:13] CIA-14 zeromq2: Don't set pedantic to yes if using ICC
[23:13] CIA-14 zeromq2: Signed-off-by: Mikko Koppanen <mkoppanen@php.net> - http://bit.ly/bwqYkn
[23:24] CIA-14 zeromq2: 03Martin Sustrik 07master * r733c678 10/ src/pipe.hpp :
[23:24] CIA-14 zeromq2: Minor code clean-up to keep clang compiler happy.
[23:24] CIA-14 zeromq2: "warning: extra ';' inside a struct or union [-pedantic]"
[23:24] CIA-14 zeromq2: Signed-off-by: Martin Sustrik <sustrik@250bpm.com> - http://bit.ly/a61tct

Web site design and content is copyright © 2010-2011 Peter Alexander, ProDataLab. Site content licensed under the Creative Commons Attribution-Share Alike 3.0 License. ØMQ is copyright © Copyright © 2007-2011 iMatix Corporation and Contributors. Contact us for professional support. ØMQ is free software licensed under the LGPL. ØMQ, ZeroMQ, and 0MQ are trademarks of iMatix Corporation. Terms of Use ? Privacy Policy