Monday June 7, 2010

[Time] NameMessage
[00:06] mikko foysavas: try again tomorrow
[00:06] mikko foysavas: sustrik can help you on that
[02:12] silassewell I understand that its not a priority right now (or possibly at all), but I was wondering if anyone was aware of any type of security mechanism successfully being layered on top of zeromq (something like tls as opposed to ipsec)?
[02:32] mikko its a complicated issue
[02:32] mikko the topic has come up more than once
[02:33] mikko the problematic thing is different needs people have and especially when you have more complex messaging topologies
[02:33] mikko such as forwarding devices that are not trusted etc
[02:37] silassewell yeah, I'm not looking for a builtin / standard solution, I was just wondering if anyone had heard of someone successfully deploying zeromq in an untrusted environment
[02:38] mikko i would imagine something like pub/priv key signing would work
[02:38] mikko adds some overhead to the messages
[02:38] mikko or just encryption
[02:38] mikko are you looking to hide the messages or guarantee integrity?
[02:40] silassewell hide the message and authenticate the sender
[02:41] mikko i guess you could follow similar pattern to email?
[02:42] silassewell yeah, I'll start experimenting with it, I just wanted to see if anyone had done it before I began
[03:50] jugg doesn't document the overloaded poll() interface, ie, that poll() can be called with or without a timeout value; if without, defaults to -1, eg. no timeout.
[05:02] jugg hmm, is it not possible to unbind/disconnect a socket from an endpoint? It seems I have to close the socket, in which case all connections and bindings for that socket are lost.
[06:37] sustrik zedas: nice, is the libtask project repo available online?
[06:38] sustrik it may make sense to link to it from website
[06:38] sustrik foysavas: yes, please do put the D binding to the github
[06:39] sustrik then let me know and I link it from
[06:39] zedas sustrik: "repo" is a bit of a stretch
[06:39] zedas but i'll have something up
[06:39] sustrik thanks, let me know then
[06:39] sustrik this stuff looks really useful
[06:39] sustrik it would be shame to let it die
[06:43] sustrik jugg: good catch about the zmq_poll in C++
[06:43] sustrik jugg: no it's not possible, you have to close the socket
[06:44] sustrik (following bsd sockets API here)
[06:47] Olivier_c hi all.
[06:49] sustrik hi
[06:53] Olivier_c sustrik, why have you removed zmq_stopwatch_start/stop in 2.07 ? i don't see anything about it in the changelog.
[06:54] sustrik it was an undocumented feature intended only for internal use
[06:54] sustrik 0mq is not intended to be a portability library
[06:55] sustrik the functions were used only by perf tests
[06:55] sustrik now they are in perf/helpers.cpp
[06:56] Olivier_c ok, thanks for the informations :) i should clean my code then .
[06:56] sustrik sorry for inconvenience, we are trying to keep the API as clean as possible
[06:57] sustrik pain now = less trouble afterwards :)
[06:59] Olivier_c no problem. i'm gonna change this, and probably come back with (still) troubles with openpgm :)
[07:04] CIA-17 zeromq2: 03Martin Sustrik 07master * rce53d02 10/ doc/zmq_cpp.txt : C++ docs for zmq::poll function improved -
[07:04] CIA-17 zeromq2: 03Martin Sustrik 07master * r784e73a 10/ (ChangeLog NEWS): Merge branch 'master' of -
[09:21] jugg what is a sensible way to recover from a REQ/REP deadlock? How does both sides of the endpoint re-synchronize when things get out of sync? How does either side ever know things are out of sync?
[09:22] mikko how do they get out of sync?
[09:24] jugg a REQ is sent, the REP never replies (it goes away). When it comes back, REQ never recovers. (I mentioned this yesterday)
[09:24] jugg The mention suggest of using Poll, has this issue:
[09:25] jugg the REQ socket state is out of order, so REQ send fails. ANd because of my above question, that it isn't possible to close a connection, the problem increases, because closing the socket is a problem.
[09:26] jugg ie. everytime poll times out, I have to close the socket.
[09:26] jugg this interrupts a bunch of other things, so it isn't an acceptable solution.
[09:26] sustrik jugg: yes, that's the current state of affairs
[09:26] sustrik this should be done inside of 0MQ
[09:27] sustrik bit it's not yet
[09:27] jugg yes, I"m trying to find a sensible work around. I htink the only option is closing the socket?
[09:27] sustrik yes
[09:27] jugg :( ok
[09:27] sustrik i know :(
[09:52] mato re
[09:52] mato sustrik: what is this business of moving repositories?
[09:52] sustrik imatix is going to maintain stable version
[09:53] sustrik sustrik/zeromq2 is my playground from now on :)
[09:53] mato so it's a fork?
[09:54] sustrik yes, it's a different repo
[09:54] sustrik those who want stable API should use imatix/zeromq
[09:54] mato then imatix should prominently announce this somehow
[09:55] mato but i guess i'll leave that to imatix
[09:55] sustrik :)
[09:55] mato you know
[09:55] mato with a roadmap
[09:55] mato issue tracker
[09:55] mato maintenance plan
[09:55] sustrik yup
[09:55] mato and so on :-)
[09:56] mato sustrik: so practically, i can keep committing to your repository if i want to make changes?
[09:57] sustrik i am going to play with berkeley sockets api there
[09:57] sustrik so it depends on what you want to commit
[09:58] sustrik if it's say a bugfix that should get to stable version asap, go for imatix/zeromq
[09:58] mato sustrik: and you will not be fixing bugs in the stable version? or will you?
[09:58] sustrik the idea afaiu
[09:59] sustrik is that zeromq/imatix now moves quickly towards the stable version
[09:59] sustrik alpha
[09:59] sustrik rc
[09:59] sustrik etc.
[09:59] sustrik sustrik/zeromq2 is my sandbox
[10:00] sustrik as for the bugs, i'll fix them in both
[10:00] sustrik but imatix/zeromq is more important
[10:00] sustrik as it's meant to be stable
[10:01] mato right, but the stability of this fork is decided by imatix presumably
[10:01] sustrik yes
[10:01] mato they have a plan
[10:01] sustrik i believe so
[10:02] mato should i ask imatix about these plans on the mailing list?
[10:03] sustrik up to you
[10:03] mato i'm just somewhat upset that the decision appears to have been made without seeking *any* input from the community or contributors
[10:04] mato without proposing any roadmap what stable means
[10:08] sustrik the point is people are compaining about unstable APIs
[10:08] sustrik fair enough
[10:08] mato people always complain
[10:08] sustrik i think 0mq have reached the point where it's used enough to deserve a stable branch
[10:08] sustrik no point in people using my sandbox for production use :|
[10:09] mato my point is that you wrote an email asking for comments on the way forward, and PH just wrote back 12hrs later with an executive decision
[10:09] sustrik i asked him to do so
[10:10] sustrik maintaining a stable branch _is_ an executive decision
[10:13] mato sustrik: i find it interesting that my input as the contributor who has been preparing the last few stable releases *for free* is not wanted
[10:13] sustrik sustrik/zeromq2 is *my* repo
[10:14] sustrik i just don't want people to come in and complain about the release policy
[10:14] sustrik it's a sandbox
[10:14] mato sustrik: that's what branches are for, damnit
[10:15] mato sustrik: you have, let me see, 129 people watching your repository
[10:15] mato sustrik: so let's face it, that repository should be the canonical source for 0MQ
[10:16] mato or, if not, it should be prominently announced, all over the place, not in an email hidden under "Stable release" on the mailing list
[10:16] sustrik sure, it should
[10:16] mato anyway, i will reply on the mailing list
[10:17] sustrik ok
[11:49] jugg sustrik: will you be pushing changes to the imatix repo as you work?
[11:49] sustrik jugg: yes
[11:49] sustrik the only point is about the API
[11:49] sustrik people using 0mq in production don't want APIs to be changed
[11:49] sustrik thus we need a "stable" repo
[11:49] sustrik ->imatix/zeromq
[11:50] sustrik my own sustrik/zeromq2 i'll use for experimenting with API
[11:50] sustrik so it's worth of following only is you are interested in reseach-related stuff
[11:50] sustrik research*
[11:51] sustrik does that make sense?
[11:56] jugg yes/no. Even if another repository is made to be the "official" one, I'd still expect the branches shared between the two repositories to remain synched, and any experimental work to be done on branches existing only in your repository.
[11:58] jugg I expect the "master" branch to be one of those shared branches that remain sync'd
[11:59] sustrik i just don't want to have the whole project under sustrik account
[11:59] sustrik it's not a one-man show any longer
[12:00] jugg makes sense
[15:24] jugg while building from source, `./configure --prefix=/some/path` is this used only for `make install`? ie, if I re-run ./configure with a different prefix, do I have to rebuild?
[15:26] sustrik jugg: no idea
[15:27] sustrik you should be able to find the answer somewhere in the autools documentation
[15:27] sustrik autotools*
[15:29] jugg when doing a full make after changing the prefix, these files differ:
[15:29] jugg ./lib/libzmq.a
[15:29] jugg ./lib/
[15:29] jugg ./lib/pkgconfig/libzmq.pc
[15:30] jugg when not doing an make, only the .a and .pc differ. The .la still points to the old directory.
[15:31] jugg but all of the files themselves were placed in the correct (updated) locations.
[15:33] jugg wierd that the static lib changes without actually doing a rebuild. ?
[15:56] CIA-17 pyzmq: 03Brian Granger 07master * rafabbb5 10/ (18 files in 7 dirs):
[15:56] CIA-17 pyzmq: Updating to new 2.0.7 API changes.
[15:56] CIA-17 pyzmq: * Context only takes the number of io threads.
[15:56] CIA-17 pyzmq: * P2P -> PAIR.
[15:56] CIA-17 pyzmq: * No stopwatch.
[15:56] CIA-17 pyzmq: * No LWM socket option. -
[15:57] guido_g ahhh... time to pull :)
[18:24] CIA-17 zeromq2: 03Martin Sustrik 07master * r240fc33 10/ src/tcp_connecter.cpp : minor comment clarification -