| [Time] Name | Message |
|
[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
|
http://api.zeromq.org/zmq_cpp.html 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 zeromq.org 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 zeromq.org
|
|
[06:39] zedas
|
sustrik: "repo" is a bit of a stretch http://swtch.com/libtask/
|
|
[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 - http://bit.ly/9IX99E
|
|
[07:04] CIA-17
|
zeromq2: 03Martin Sustrik 07master * r784e73a 10/ (ChangeLog NEWS): Merge branch 'master' of git@github.com:sustrik/zeromq2 - http://bit.ly/aAMj5O
|
|
[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/libzmq.la
|
|
[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. - http://bit.ly/9vHx2a
|
|
[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 - http://bit.ly/9qdEMQ
|
