Re: [zeromq-dev] BDFL team

[Wes Young]

From those of us on the fringe- can’t say thank you enough to both of you [and 
countless others] for picking up where P left off.. and running with it. I try 
to use this community as “the” example of how development SHOULD… err MUST be 
done in order to be successful. Open-source or otherwise.. ;)

Kudos Luca- Keep it up!

> On Jan 3, 2019, at 6:41 AM, Doron Somech  wrote:
> 
> I'm very happy to announce the Luca accepted my invitation to join me in the 
> BDFLs team, thank you Luca.

—
wes



signature.asc
Description: Message signed with OpenPGP
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] There's been an issue with your automated build

[Wes Young]

https://github.com/zeromq/czmq/pull/1942/files#diff-3254677a7917c6c01f55212f86c57fbf

specifically.

> On Oct 4, 2018, at 2:22 PM, Wes Young  wrote:
> 
> i wonder if that was me? i just pushed some zproject refresh changes to czmq 
> and i did notice some (a few what looked to be minor? docker tweaks..)
> 
> (i’ve not looked at how hub.docker ties into the build, but skimming the 
> timestamps..)
> 
>> On Oct 4, 2018, at 1:38 PM, Benjamin Henrion  wrote:
>> 
>> Ah someone is trying to build something :-() Hackaton in progress?
>> 
>> -- Forwarded message -
>> From: 
>> Date: Thu, Oct 4, 2018, 19:36
>> Subject: There's been an issue with your automated build
>> To: 
>> 
>> 
>> Hi Benjamin Henrion,
>> 
>> There seems to have been an issue with your Automated Build "zeromqorg/czmq" 
>> (VCS repository: zeromq/czmq) during the build step.
>> You can find more information on
>> https://hub.docker.com/r/zeromqorg/czmq/builds/bbl3f9pyfkdhnqdktvxkvtl/
>> ___
>> zeromq-dev mailing list
>> zeromq-dev@lists.zeromq.org
>> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
> 
> --
> wes
> wesyoung.me
> 

--
wes
wesyoung.me



signature.asc
Description: Message signed with OpenPGP
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] There's been an issue with your automated build

[Wes Young]

i wonder if that was me? i just pushed some zproject refresh changes to czmq 
and i did notice some (a few what looked to be minor? docker tweaks..)

(i’ve not looked at how hub.docker ties into the build, but skimming the 
timestamps..)

> On Oct 4, 2018, at 1:38 PM, Benjamin Henrion  wrote:
> 
> Ah someone is trying to build something :-() Hackaton in progress?
> 
> -- Forwarded message -
> From: 
> Date: Thu, Oct 4, 2018, 19:36
> Subject: There's been an issue with your automated build
> To: 
> 
> 
> Hi Benjamin Henrion,
> 
> There seems to have been an issue with your Automated Build "zeromqorg/czmq" 
> (VCS repository: zeromq/czmq) during the build step.
> You can find more information on
> https://hub.docker.com/r/zeromqorg/czmq/builds/bbl3f9pyfkdhnqdktvxkvtl/
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> https://lists.zeromq.org/mailman/listinfo/zeromq-dev

--
wes
wesyoung.me



signature.asc
Description: Message signed with OpenPGP
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] dealing with stale github issues

[Wes Young]

wfm. i dunno that the number is all that important as long as it’s something 
predictable and helps keep things clean. stalebot is nice because it takes into 
account issues where there is still activity. it’s not until an issue goes 
dormant (thread wise) that it starts to kick in the timer (which may or may not 
be useful). so even if you picked “1 year” it’s “it’s been a year since someone 
commented on this issue…” not “the issue been open a year”.

and again, a new comment can just as easily re-open the issue too.

ymmv, but you get the idea.

> On Sep 30, 2018, at 6:05 AM, Luca Boccassi  wrote:
> 
> For libzmq every now and then we do a manual pass and try to close old
> issues that we know have been solved - I've done this last year, Simon
> did it more recently, but yes old issues rot. For libzmq perhaps
> something like 2 years would be more appropriate.

--
wes
wesyoung.me



signature.asc
Description: Message signed with OpenPGP
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

[zeromq-dev] dealing with stale github issues

[Wes Young]

hi,

as i’m catching up on my somewhat stale czmq/zyre/tls/gossip/tls forks, i’m 
weeding through the issues on czmq and zyre and thinking “2016? is this still 
an issue?” for a number of my own github projects i’ve started enabling the 
stale app on github to just remove things that either aren’t problems or aren’t 
problems worth solving.

https://github.com/apps/stale

has anyone brought this up for some of the zeromq repo’s (i may even have, i 
forget)? i’m a little more aggressive with my own repo’s (assuming people log 
issues and don’t submit a PR to fix the problem, after 21-45 days they get 
closed). having spent the last few years digging through the guts of ZAP, TLS, 
Zyre, GOSSIP, etc.. 21 days may be a bit harsh… maybe something simple like 
12mo for some repo’s and see how it plays out?

the biggest concern i have is [for myself] figuring out what and where i can 
dive into stuff when i have a spare cycle here and there- i can only imagine 
some new users might feel the same overwhelming “where do i start?” when 
looking at obviously stale issues that go back to 2016, 2015.. or worse- “this 
project has too many bugs! and clearly no one is paying attn”.

even if you wanted to fix some of them, you’d have to start over again (find 
the original complainer, get data, etc) anyway. i’ve tried that a few times, 
things just go stale, people get busy and it doesn’t help that these projects 
sometimes move really fast, leaving some of these issues irrelevant anyway.

if i owned the world, it feels like 6-9mo is a good number, 12mo is probably a 
good start though for projects like this imo. it’s not like you can’t find 
these later if they re-surface (and re-open), but it’s a lot of noise imo. i’m 
thinking Zyre (and maybe czmq?) might be a good place to test this? thoughts? 
has this been brought up before (and squashed)?

this community has done a great job at keeping the PR queue clean, something 
that’s brainwashed me into HATING ANY PROJECT that doesn’t do that. i think the 
issues queue is the next step in that evolution.

happy to take critisism's, just trying to make it easier to get involved w/o 
having all the legacy baggage. ymmv.

thanks for all that everyone here does!
--
wes
github.com/wesyoung
csirtgadgets.com



signature.asc
Description: Message signed with OpenPGP
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] zproto- terminated events

[Wes Young]

[for the search archives]

> On Feb 16, 2018, at 9:00 AM, Wes Young <w...@barely3am.com> wrote:
> 
> (looking at zgossip.c and zgossip_engine.inc, and using versions that are 
> in-sync with current zproto master)
> 
> in zproto should a “termination” state trigger a socket disconnect (eg: a TCP 
> FIN?) in the state machine? or is this something that needs to be handled in 
> your server code? and it’s just assumed the TCP state stays ‘open’ unless 
> you’ve implemented some lower level heart-beats or actually force a term of 
> the tcp socket itself(?)
> 
> for instance- when zgossip triggers an expired/term event- the state goes to 
> term and it appears to remove the client from it’s list(?), but it never 
> seems to clean up the TCP connection unless there’s a hard disconnect. i 
> can’t tell if this is on purpose and supposed to be done in the client, or if 
> that’s just where folks left off last.. along with PING/PONG/TTL, 
> zgossip.c:client_terminate is empty atm.

this is really more of a lower level zmq feature that i musta brain-farted on. 
the client is really responsible for the initiating a FIN, which is fine. the 
other issue seems to be, unlike other zproto protocols gossip *can* be really 
quiet at times. the zproto application server thinks the client is gone, but a 
FIN never went through (there was no lower level zmq disconnect). the other 
protocols seem to get around this issue by being more chatty, having longer 
timeouts and the correct implementation of PING/PONG which was started in 
gossip, but not quite finished (testing a PR for this).

also testing some TTL ideas that will influence the timeouts (eg: when things 
go quiet).

> i’m looking through the zproto docs and examples and think i’m just missing 
> something dumb here.. might be mixing some terms too.

--
wes
wesyoung.me



signature.asc
Description: Message signed with OpenPGP
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

[zeromq-dev] zproto- terminated events

[Wes Young]

(looking at zgossip.c and zgossip_engine.inc, and using versions that are 
in-sync with current zproto master)

in zproto should a “termination” state trigger a socket disconnect (eg: a TCP 
FIN?) in the state machine? or is this something that needs to be handled in 
your server code? and it’s just assumed the TCP state stays ‘open’ unless 
you’ve implemented some lower level heart-beats or actually force a term of the 
tcp socket itself(?)

for instance- when zgossip triggers an expired/term event- the state goes to 
term and it appears to remove the client from it’s list(?), but it never seems 
to clean up the TCP connection unless there’s a hard disconnect. i can’t tell 
if this is on purpose and supposed to be done in the client, or if that’s just 
where folks left off last.. along with PING/PONG/TTL, 
zgossip.c:client_terminate is empty atm.

i’m looking through the zproto docs and examples and think i’m just missing 
something dumb here.. might be mixing some terms too.
--
wes
wesyoung.me



signature.asc
Description: Message signed with OpenPGP
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Design problem of distributed environment

[Wes Young]

i’m not quite sure on the current status of pyre- iirc it’s a “pure python” 
implementation of zyre which doesn’t use the zyre/czmq libraries. seems like 
there have been some recent commits, so it appears still active.. just not sure.

we’ve been developing another version (that’s becoming moderately stable, 
slowly but surely):

https://github.com/wesyoung/pyzyre

but with the caveat that you have to really understand how to build- and 
install the czmq and zyre C libs (pyzyre tries to do some of this for you, but 
it’s not very user friendly at the moment).

if you do get your hands dirty (i don’t recommend this as a new user; just 
citing it as examples); you can see some of the ways we’ve been testing this 
“thin python layer on top of C”:

https://github.com/wesyoung/pyzyre/blob/master/pyzyre/gateway.py
https://github.com/wesyoung/pyzyre/blob/master/pyzyre/client.py
https://github.com/wesyoung/pyzyre/blob/master/pyzyre/broker.py

but it’s probably overkill for what you’re trying to do as a prototype (the 
nuances between the libs are still not 100% flushed out or even in stable 
releases). getting zeromq/pyre (pure python) working on the LAN via udp beacons 
is probably your best bet in understanding zyre- then if you need to do other 
things (like crypto or gossip or..) working your way down to the C level when 
you have more time to pull this off may be worth the effort...

> On Nov 15, 2017, at 2:14 PM, Matej Puk  wrote:
> 
> I am trying to implement some simple example using pyre but with no luck so 
> far. Do you have any experience with pyre or zyre?

--
wes
wesyoung.me



signature.asc
Description: Message signed with OpenPGP
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Design problem of distributed environment

[Wes Young]

> I am currently fighting with some design issues for my project and as newbie 
> to zeroMQ I am here to look for advice. My project should simulate 
> distributed algorithm in distributed environment.

welcome :)

> For example algorithm like brodcasting. I need to implement communication 
> between nodes in this environment and I chose to use zeroMq.
> 
> My question is what do you think is the best approach when you want to design 
> environment where entity must do following:
> be able to receive messages from neighbours,
> be able to send message to all or maybe few selected neighbours.
some of this may depend how you define “a neighbor” (e.g.: pre-configured env, 
or zero-conf env). if you’re looking for little-to-zero configuration, may 
wanna checkout zyre:

https://rfc.zeromq.org/spec:36/ZRE 
https://github.com/zeromq/zyre My first idea 
was to give very entity a ROUTER socket. Is it possible to achieve it with only 
routers?
> 
I believe so- but you may wanna start by reading about the different patterns 
first and prototyping some simple one to one, one to two patterns to get your 
hands dirty first, get a feel for the different socket types:

http://zguide.zeromq.org/page:all#Messaging-Patterns 


You probably start out with REQ/REP which is easy- then move into async 
(router/dealer) then into something like Zyre where the learning curve is a 
little steeper (but probably closer to what you want long term if I’m 
understanding your question).
> As I looked at ROuter it can send message to multiple nodes and also can 
> receive messages from multiple nodes.
> 
> Every entity knows who is it's neoghbor and have information about IP's and 
> ports.
> 
Yea, sounds like a problem ZYRE solves- but if you’re new may wanna work your 
way into it a bit with some of the simpler types first..

make sense?

—
wes
wesyoung.me


signature.asc
Description: Message signed with OpenPGP
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Zyre demo at OpenWRT Summit in Prague, last Pieter's project

[Wes Young]

+1

:)

> On Oct 26, 2017, at 7:15 AM, Brian Knox via zeromq-dev 
>  wrote:
> 
> It was great watching this while drinking my morning coffee today!

--
wes
wesyoung.me



signature.asc
Description: Message signed with OpenPGP
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] thread safety using inproc sockets for inter-thread communication

[Wes Young]

[i’m only able to skim this atm but..]

have you looked at how zauth works in czmq (using the actor models):

https://github.com/zeromq/czmq/blob/master/src/zauth.c
https://rfc.zeromq.org/spec:27/ZAP/

it sounds similar [at-least as an example], or at-least any of the “actors” in 
zeromq kinda work.. (although sounds like zauth is the closest because it’s 
inproc).

may not be 1-1 but at-least some more up to date examples..

> On Sep 27, 2017, at 5:52 PM, Bill Torpey  wrote:
> 
> 
> Can anyone suggest a solution?  I can’t really see any other way to do 
> inter-thread communication safely with ZeroMQ.
> 
> Any hints, tips, suggestions would be much appreciated!  And, let me know if 
> this would be better discussed in GitHub issues.

--
wes
wesyoung.me



signature.asc
Description: Message signed with OpenPGP
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] czmq -- zauth.api (missing?)

[Wes Young]

of course- if i was smart, i would have looked at some more of the examples 
first:

https://github.com/zeromq/czmq/blob/master/bindings/python/test.py#L40

i was mistaken that project.xml DID have it as an  which means the 
start function was defined in _prelude.h, was just a matter of finding that and 
figuring out how to access it through the python layer..

however, i started re-writing a bit of it similar to how zyre_node_t, 
zgossip_t, etc [and others] are setup- to see what it’d look like and see how 
the higher level bindings reacted towards it. it *seems* like it would 
transition smoothly and provide some easier access functions to the higher 
level bindings, instead of having to pass strings back and forth. not that it’s 
a big deal either way- but seems like it’d be more consistent with the rest of 
the APIs (?)

just a matter if others have found really big show stoppers in teh past- or “no 
dummy don’t do that cause blah”. don’t wanna mess up zauth for people here..

(thinking out-loud)

> On Sep 20, 2017, at 6:13 PM, Luca Boccassi  wrote:
> 
> I think it's simply never been converted, IIRC it predates the zproject
> api models. There are other classes as well that haven't been ported.
> If you send a PR to add api/zauth we'll merge it.

--
wes
wesyoung.me



signature.asc
Description: Message signed with OpenPGP
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] encryption for zyre, presentation at next OpenwrtSummit in Prague

[Wes Young]

which after this PR- should work quite a bit better..

https://github.com/zeromq/zyre/pull/560

fwiw,

> On Sep 14, 2017, at 5:19 PM, Wes Young <w...@barely3am.com> wrote:
> 
> you will need the latest czmq master which has similar changes in to to 
> configure gossip for curve-

--
wes
wesyoung.me



signature.asc
Description: Message signed with OpenPGP
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] czmq -- zauth.api (missing?)

[Wes Young]

ack-

figured as much, just wanted to be sure.. see if i can’t get something bang’d 
out..

> On Sep 20, 2017, at 6:13 PM, Luca Boccassi  wrote:
> 
> I think it's simply never been converted, IIRC it predates the zproject
> api models. There are other classes as well that haven't been ported.
> If you send a PR to add api/zauth we'll merge it.

--
wes
wesyoung.me



signature.asc
Description: Message signed with OpenPGP
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

[zeromq-dev] czmq -- zauth.api (missing?)

[Wes Young]

is there a reason for not having a zauth.api ?

i get that via C you approach it via zactor_t but i’m finding with the 
generated bindings (python) i have to pyzmq around it with 
zmq.auth.thread.ThreadAuthenticator beacuse i don’t see exposure of “zauth” so 
i could spin up a zactor_t of it.

am i missing something stupid? easy enough to build zauth.api and overwrite 
zauth.h so the language bindings have access to it? or should i just be using 
zactor and zactor_fn (or something else) to spin up a zauth actor?

--
wes
wesyoung.me



signature.asc
Description: Message signed with OpenPGP
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] encryption for zyre, presentation at next OpenwrtSummit in Prague

[Wes Young]

https://github.com/zeromq/zyre/pull/554

talk about great timing :)

check out the tests- the way i implemented was to leave all the config magic to 
your app- just pass the keys down the stack and the lower bits do all the right 
things (i think, in that phase where the more people that bang on it the 
better).

beacon seems to work OK (in very limited testing), i put forth a “ZYREv3” rfc 
to start covering how keys could be advertised locally on the network (both in 
the beacon packet itself- as well as using X-PUBLICKEY headers). not meant to 
be “great” encryption- but enough to get your feet wet in a sandbox. there may 
be some issues with gossip (that may or may not have been related to curve) 
that i need to work out next, so that may or may not work/scale well.

you will need the latest czmq master which has similar changes in to to 
configure gossip for curve-

it’s a really rough start- but a start. happy for some [smarter people that i] 
to bat it around a bit.

> On Sep 14, 2017, at 5:00 PM, Benjamin Henrion  wrote:
> 
> Now I would like to know if the curve encryption feature could already
> be used in some form, and how to set it up.
> 
> That was basically the last Pieter's project he presented at his last
> conference.
> 
> I have received today a bunch of glar150 routers, and some Allwinner
> H2 Orangepi Zero, which should run armbian but not yet openwrt/lede.

--
wes
wesyoung.me



signature.asc
Description: Message signed with OpenPGP
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] travis testing -- udp broadcasts and valgrind

[Wes Young]

that’s the impression i was getting from the host strings- it had just been a 
long day [of banging my head against the wall- chasing an actual valgrind issue 
on default- and this one].

the kicker was, the czmq stuff builds (zbeacon, etc). and that’s what threw me 
off- till i started narrowing down the diff in vm’s (all the way down to the 
compile flags).

turns out- `ifconfig` saves the day (*face-palm*)

thanks for this- i’ll fiddle with it see if i can get it working (and maybe a 
test for broadcast that highlights the underlying issue and STDOUTs something 
useful..)

> On Sep 14, 2017, at 6:46 AM, Luca Boccassi  wrote:
> 
> IIRC with sudo-enabled jobs it's a GCE VM, with sudo-disabled jobs it's
> a container
> 
> There's no reason for that sudo: required anymore, so feel free to take
> it away (I've already removed it from czmq, probably forgot to do the
> same elsewhere), it should fix your problem
> 
> Unfortunately doing networking on Travis is a bit of a pain... had some
> fun setting up an IPv6 enabled job a while back in libzmq

--
wes
wesyoung.me

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

[zeromq-dev] travis testing -- udp broadcasts and valgrind

[Wes Young]

those of you that have messed with travis and the zmq build infra-

i seem to be hitting the wall in testing udp-beacon stuff (zyre + curve) with 
the valgrind test. the default tests pass- but as soon as you load up the 
valgrind vm it comes to a screeching halt.

i finally threw an `ifconfig` into the ci_build.sh to figure out why i can send 
beacons, but they’re never recv’d (again, this all works on the default build 
via travis, locally, etc). and it appears that the valgrind build (which really 
is just adding sudo? maybe some more docker bits?) sets the eth0 broadcast to 
255.255.255.255 instead of 255.255.0.0

https://travis-ci.org/wesyoung/zyre/jobs/275250344#L624
https://travis-ci.org/wesyoung/zyre/jobs/275250349#L640

has anyone else run into this with their travis+(c)zmq adventures? i need to do 
some more digging, but in the correct build there’s no docker adapter, but in 
the valgrind build there is-

based on the hostname strings, it almost looks like i’m either in a docker 
instance where i can do broadcasts (non-sudo) and when i’m using sudo- i’m 
outside the instance where broadcast is more locked down(?)

obvs i need to dig more into travis doc, curious if anyone has run into this- 
and if not, posting for posterity.
--
wes
wesyoung.me



signature.asc
Description: Message signed with OpenPGP
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] zyre : gossip and evasive

[Wes Young]

iirc: the way the PING/PONG works- if nodes don’t see traffic from each-other 
in 5s (?) they send an EVASIVE up the stack and send a PING/PONG. so if you’re 
nodes are NOT “chatty” you may see lots of these if you don’t adjust the timers.

you may want to fiddle with the TIMEOUTs.

https://github.com/zeromq/zyre/blob/master/api/zyre.api#L63

an ex in python:

https://github.com/wesyoung/pyzyre/blob/master/pyzyre/_client_task.py#L13

as far as EXITs, i forget off hand but i don’t think they are required(?) may 
have to double check the protocol. i *think* LEAVE is required for when you 
LEAVE a group, but EXIT may be something different.

are you doing this using one of the bindings? or C itself?

> On Aug 23, 2017, at 7:53 AM, brunobodin .  wrote:
> 
> I am currently integrating zyre in my system, and I would like to be able to 
> equally use udp and gossip discovery.
> 
> I noticed that when I start two nodes using gossip discovery, I soon see 
> evasive events, which do not occur when using UPD : is this "work as 
> designed" ? It looks strange to me to have different behaviour
> 
> More annoying : when using the gossip discovery, when a node stops, the EXIT 
> event is not received  by the other one ?
> 
> Thanks for you help

--
wes
wesyoung.me



signature.asc
Description: Message signed with OpenPGP
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] zyre and curve key exchange

[Wes Young]

i think i did this right, but not sure- first time PR’ing to RFC:

https://github.com/zeromq/rfc/pull/123

i’m still doing testing in my local ZYRE branch to make sure this RFC “works 
IRL”, but effectively the gist is:

https://github.com/wesyoung/rfc/commit/8fbebfa8e326701458b3282246ef92a20dba38af

which adds a 32-byte field to the end of a beacon packet. in the 
implementation, if you have “curve enabled” zyre will ignore non v3 packets 
(eg: v2 packets) to avoid downgrade. if you don’t have curve enabled (eg: no 
public key set), it’ll accept v2 packets.

the zyre bits themselves mostly work- just cleaning up some of my rusty C work 
and checking for leaks. also- because the protocol version is changing, trying 
to stumble my way through re-creating the protocol bits with zproto(?) which is 
a bit awkward. need to do some more reading (unless im missing something stupid 
here..).

comments welcome,

> On Jul 15, 2017, at 5:38 AM, Luca Boccassi  wrote:
> 
>>> Perhaps add it as an option, but fail hard if it is enabled and the
>>> peer does not support it. This way backward compatibility by
>>> default
>>> can be saved, but if enabled it's robust against downgrade.
>> 
>> i like this idea. may run with it a bit. it’s *probably* a new
>> version of the RFC, just to be consistent, and then doing what you
>> describe, make sure it’s not a default, but that you set it and it
>> locks down. if only to see how it reacts in the wild.
> 
> It would be a new RFC yes, but it's fine, we can create version as
> DRAFT and follow the usual process. Feel free to send a PR to create it
> in zeromq/rfc, doesn't matter if it's rough on the edges, we can
> iterate as needed.

--
wes
wesyoung.me



signature.asc
Description: Message signed with OpenPGP
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] zyre and curve key exchange

[Wes Young]

ack, i’ve tested it both ways. figured i’d float the overloading idea since 
it’s a bit more concise, but could lead to confusion.

i’ll re-factor as an actor call (with the extra headers involved with 
server_connect, etc) and see how it looks (a bit more gsl hacking todo-). i 
don’t have a strong opinion either way, wva makes it easier to adopt.

as i was flipping through the various ways endpoints are used in _bind|_connect 
and i don’t think there’s an RFC for that(?). not that their needs to be, but 
the way PH has apparently brainwashed me over the years, was surprised there 
wasn’t. :)

> On Jul 15, 2017, at 5:38 AM, Luca Boccassi  wrote:
> 
> I would recommend using actor calls rather than overloading.
> 
> The endpoint format is already very overloaded and a bit confusing as
> it is, having clear API calls is much cleaner and understandable for
> users and developers IMHO.

--
wes
wesyoung.me



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Architecture design

[Wes Young]

np, i’ve found it esp useful in projects where not all users are native english 
speakers [and/or i’m not the native language speaker, more appropriately]. 
something simple to communicate a set of concepts.

it’s quick and dirty, gets the point across so we can build things. glad you 
found it useful. :)

> On Jul 13, 2017, at 2:08 PM, Harald Achitz  wrote:
> 
> wow did not know  http://asciiflow.com/ , thanks!
> 
> being able to draw such diagrams has been the only reason for me to use 
> emacs, using artist mode,
> but this is better, resizin nd moving the squares, so easy!

--
wes
wesyoung.me



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] zyre and curve key exchange

[Wes Young]

> On Jul 13, 2017, at 1:54 PM, Luca Boccassi  wrote:
> 
> As usual I would suggest to follow our process, and send a PR with what
> you have as DRAFT.

ack. did a first pass with #ifdef DRAFT, etc… now starting to clean up the 
gsl/xml bits and test to make sure the headers are correct.. have a sep build 
process parallel to yours on opensuse to test this in our live env while we 
figure out the nuances [for those that want to play along].

https://github.com/zeromq/zyre/compare/master...wesyoung:feat/curve?expand=1
https://github.com/zeromq/czmq/compare/master...wesyoung:feat/curve?expand=1

the thing i’m trying to work around is creating too many custom headers (which 
is easy todo, just looks awkward). so first attempt is/was to overload the 
SET/CONNECT variables and pick them apart before we connect/bind. which doesn’t 
break zmq_bind|zmq_connect but it does make the actors a little less … 
consistent.

i have a feeling, for the sake of consistency the better way is going to be 
setting each of the keys via the normal actor calls [which we started out 
doing, just more code vs overloading the endpoint SET] and passing the vars 
through the headers to the correct functions.

there are a few [simple] zcert functions that i think are no-brainers to PR 
sooner than later, just cleaning up the obvious gsl/xml stuff there too.

> I don't think the zbeacon protocol change can be made backward
> compatible unfortunately, as the library checks for the exact size of
> the beacon, and discards if it doesn't match.
> 
> Also not sure it should in the first place - given it's a security
> feature, it would open up to a downgrade attack. There were CVEs in
> libzmq with the exact same problem when Curve was first introduced.

that makes sense. i kinda figured i was playing with fire on that one, but 
exploring the idea, getting it to work, etc. i hate having to do so much manual 
work (exchanging keys, etc) just to test stuff. it’s a pita (like having to 
remember wifi keys for basic tls functions). i get why, trying to think outside 
the box.

back to the drawing board.

> Perhaps add it as an option, but fail hard if it is enabled and the
> peer does not support it. This way backward compatibility by default
> can be saved, but if enabled it's robust against downgrade.

i like this idea. may run with it a bit. it’s *probably* a new version of the 
RFC, just to be consistent, and then doing what you describe, make sure it’s 
not a default, but that you set it and it locks down. if only to see how it 
reacts in the wild.

> Also note that it's not only on a local network anymore, zbeacon
> supports IPv6 multicast and although rare and difficult, it is possible
> to use it beyond the LAN boundaries.

you should see the env we’re testing this in (*heavily* Internet2 enabled ;), 
which is sorta why i’m asking some of these questions..).

thanks for this, very helpful :)
--
wes
wesyoung.me



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] zyre and curve key exchange

[Wes Young]

> On Jul 12, 2017, at 12:19 PM, Benjamin Henrion  wrote:
> 
> We discussed adding encryption support to Zyre at last fosdem zeromq
> hackaton, where we were using the glard daemon.

interesting, have to check it out. assuming that’s this:

https://github.com/CodeJockey/glar150

> I think the simplest use case would be to distribute keys in a "wifi
> pre-shared-key way", like a shared password to decrypt a specific zyre
> channel. I think in the glard case the channel was hardcoded to a
> specific value.
> 
> The idea with encrypted zyre was that your fridge could discover your
> TV, and if the manufacturer would have set the crypto keys in advance,
> both devices could talk to each other in an encrypted way.

understood. the patches i’m working on should cover that- basically just 
sending the keys down to the various actors and applying them to the sockets 
leaving “how you exch” at the higher levels. it’s that last step about “is 
there also a way to enable TLS out-of-the-box” part. because i may do 
authorization a diff way (and it may be a bit more fluid)…

ty for this. helpful.. :)
--
wes
wesyoung.me



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

[zeromq-dev] zyre and curve key exchange

[Wes Young]

[thinking out-loud here, seeing if anyone is thinking about this]

tl;dr: has anyone messed with “overloading” beacon or gossip generally 
speaking? (curve or o/w).

i’m mapping curve down through zyre [and gossip] (using ZAP, etc), i’ve got a 
prototype working but thinking about trivial ways to enable basic public key 
exchange (forcing some of that up to ZAP where possible). starting with some 
trivial stuff, and working up towards the more complex issues (verification, 
key signing, etc).

i’m messing with the idea of modifying zbeacon packets to broadcast a peer’s 
public key along with their uuid, which seems to work OK, but prob requires a 
new ver of beacon RFC.

i rlz it may not make sense to enable crypto on a local lan where beacon works, 
but with the idea of zyre being “zeroconf” and helping people get their feet 
wet with zyre+curve, it presents an interesting use case for zyre+curve and 
getting folks to the next step w/o having to really get into the nitty details 
of authenticated keys first.

cheap, auto-negociated TLS at the expense of “breaking" current beacon RFC 
(although i can prob find a way around this since beacon is supposed to 
disregard ‘bad’ packets anyway?) also, spending some thought on how to map this 
to gossip (might need to overload endpoint PUBLISH or modify gossip_msg to 
signal keys where they exist).

judging by older threads, most people focused on the “central directory” model 
around making sure keys are “verified”, which is where i think you want to get. 
however i also think there’s something to be said for enabling semi-verified 
TLS where you can as you think through the problem (eg: using self-signed certs 
while you figure out how signed cert process fits into your app). curious if 
others are/have ventured down this path with zyre…

i think at the point in which i’m trying to break current RFC’s, it’s prob a 
good time to stake a step back and sanity check my view of the problem… i’d 
like a semi-in-band way of advertising public keys if it makes sense. i guess 
the work-around is a secondary oob service like others have done to “do 
essentially the same thing”.

i get that udp is ‘harder to trust’ than TCP (but we’re accepting that risk 
with the uuid already). similar for gossip, although we can build some 
verification into the gossip host too to aid with that instead of having to 
enable additional services (i think?)

feedback welcome.

--
wes
wesyoung.me



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Architecture design

[Wes Young]

i like:

http://asciiflow.com/

forces you to keep things simple :)

> On Jul 6, 2017, at 3:48 AM, picfl...@web.de wrote:
> 
> what is the preferred way if I have questions regarding a concrete 
> architectural design using zeromq.
> I could draw it and attach it as a pdf, but that seems always suspicious to 
> me to open pdfs from unknown people.
> Or is there something similiar to pastebin, where I could upload that sketch 
> of my design?

--
wes
wesyoung.me



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] zproject generated bindings

[Wes Young]

> On Apr 9, 2017, at 9:56 AM, Luca Boccassi  wrote:
> 
> I think it's just that nobody needed them in the dist tarball until
> now.

aye.

> If you do, please feel free to send a PR to zproject to add them.

will do. just wanted to be sure it wasn’t for a good reason :)

i’ve seen other projects in the past with this sort of structure do things like:

$ ./configure —enable-pthon|java|etc which takes care of deploying the bindings 
but on a per-need basis [at the exp of incurring extra dep overhead for the 
distro too).. which i thought was kinda neat, but i know some of this stuff 
comes down to community preference too.

ty!
--
wes
wesyoung.me



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Zyre 2.0.0 release tagging - last chance to review APIs

[Wes Young]

for OSX homebrew users, i submitted this last night:

https://github.com/Homebrew/homebrew-core/pull/12207

bang on it and improve on it if you find it useful.

> On Jan 21, 2017, at 8:15 AM, Kevin Sapper  wrote:
> 
> we successfully released version 2.0.0 of Zyre yesterday.

--
wes
wesyoung.me



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

[zeromq-dev] zproject generated bindings

[Wes Young]

dumb question:

https://github.com/zeromq/czmq/tree/master/bindings

is it “poor form” or “just an oversight" to include these as part of the make 
dist in each of the projects? i know they’re in the “source” releases, but not 
the distribution releases. they don’t need to be installed with the default 
“make install”, but they might be useful to have handy if you “pull the 
release” and are working with the “official source” (rather than a tag where 
you have to determine your own sha1sums … imo).

https://github.com/zeromq/czmq/releases/download/v4.0.2/czmq-4.0.2.tar.gz

vs

https://github.com/zeromq/czmq/archive/v4.0.2.tar.gz

subtle diff, dunno that it matters all that much either way. mostly has to do 
with some of the [python] build systems i’m building and how the github urls 
get generated (along with passing along the correct hashes, etc).

i can do a PR if it’s just an oversight. thoughts?
--
wes
wesyoung.me



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] zmq4/czmq/zyre package building and hosting

[Wes Young]

> On Mar 3, 2017, at 1:55 PM, Luca Boccassi  wrote:
> 
> If you package up pyzyre and add an OBS service (zproject builds them
> automatically) then just send an OBS request and we'll build it there
> too.

ack.

> Also if it's mature enough please consider moving it to the ZeroMQ
> Github org!

very much still in the experimental stages; but that’s the goal.. (similar to 
the pyczmq thread we had back in .. dec?). we’re banging on it quite a bit, 
just not there yet (but also why i started asking build questions as we’re 
getting into various forms of deployment).

--
wes
wesyoung.me



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] zmq4/czmq/zyre package building and hosting

[Wes Young]

rock on.

as we're building pyzyre (which includes some embedded-ness across the 
platforms and all three of the major libs), started running into scenarios 
where having those up-to-date just made sense. figured if i’m having this prob; 
others are/or-shortly-will.

i’ll keep an eye on the progress and try to apply some cycles where it makes 
sense.

keep up the great work peeps! :)


[1] https://github.com/wesyoung/pyzyre

> On Mar 3, 2017, at 10:17 AM, Luca Boccassi  wrote:
> 
> I'll now proceed to copy over all the packages, and then switch the
> Github hook.

--
wes
wesyoung.me



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

[zeromq-dev] zmq4/czmq/zyre package building and hosting

[Wes Young]

i’m googling around a bit and trying to figure out where to apply some 
package-building / hosting effort for zmq packages (and trying to keep them up 
to date with the latest releases, maybe even the bleeding edge stuff too).

https://build.opensuse.org/project/requests/network:messaging:zeromq

is this live? and/or could use some help?

or is anyone working on a project to build/host the most recent releases (not 
just zmq, but also czmq, zyre too)? if not; i’m thinking about applying some 
effort to it, but didn’t wanna go re-inventing wheels, etc..
--
wes
wesyoung.me



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] No UDP broadcast message received using CZMQ zbeacon on RaspberryPi3

[Wes Young]

but is that what interface your app is listening (err telling zbeacon to listen 
on) for beacons on?

(in addition in making sure you’re using the latest ver), follow the 
ZSYS_INTERFACE var a bit (it may or may not be set and be associating the 
beacon listener with the correct interface…)

> On Nov 28, 2016, at 9:42 AM, Rodrigo Madruga  
> wrote:
> 
> Broadcast messages are indeed reaching the pi, as shown by tcpdump:
> 
> pi@raspberrypi:~ $ sudo tcpdump udp port 5670
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on wlan0, link-type EN10MB (Ethernet), capture size 262144 bytes
> 13:33:56.203230 IP [REDACTED].5670 > 192.168.1.255.5670: UDP, length 22
> 13:34:01.072476 IP [REDACTED].5670 > 192.168.1.255.5670: UDP, length 22

--
wes
wesyoung.me



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

[zeromq-dev] curve public key distribution (and zyre?)

[Wes Young]

[i’m kinda sorta thinking out-loud here, seeing if this strikes a chord with 
anyone, see if i’m missing something stupid here..]

i’m wondering if anyone has examples (or war-stories) of this in the wild 
distributing curve public keys outside of what the doc thus far spec’s… the 
good, bad, ugly? short of posting them in a binary[1], or to a web page, maybe 
creating a public side channel (good ole REQ/REP) that hands out the key sorta 
like pgp.mit.edu does for GPG. let’s also assume at this stage, you don’t care 
who’s on the network, just that the traffic is encrypted (push those other 
problems higher up the stack for the time being).

i’ve dug through some of the archives which talks a little about the theory 
between CA’s and WoTs, thinking about this from a Zyre[2] perspective where it 
may be less easy to keep track of all the public keys. course if you’ve messed 
with zyre and/or gossip at all, one of the things that first pops to mind is 
setting a header for the gossip traffic that not only highlights the endpoint, 
but the public cert of that end-node.. which seems logical, just a matter if 
it’s rational (again, if you don’t care who’s on the network) and where to 
bootstrap the initial gossip traffic (if you wanted to TLS gossip and the 
initial connection). this doesn’t work well in beacon, but that may be a non 
issue for other reasons.

+ connect to initial gossip node via non gossip channel that hands you it’s 
public key
+ connect to gossip channel with public key (assume we’ve patched czmq to deal 
with this at the socket level)
+ work gossip through encrypted channel
+ pull down list of peers and each of their public keys
+ connect to peers directly since we have their public keys

i think some of the answers are contained within the 2015-January thread, just 
curious if there were more war-stories out there, what works, what doesn’t, 
etc..


[1] http://lists.zeromq.org/mailman/private/zeromq-dev/2014-April/025394.html
http://lists.zeromq.org/mailman/private/zeromq-dev/2015-January/027703.html
http://lists.zeromq.org/mailman/private/zeromq-dev/2015-June/028551.html

[2] https://github.com/zeromq/pyre/issues/94
--
wes
wesyoung.me



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] ZeroMQ 4.2 release, planning

[Wes Young]

+1

with the pace czmq and zyre are beginning to move at, unless we start cutting 
releases every few weeks/months we’re probably using this methodology for a bit 
while things evolve and settle.. [which is OK, should make it easier to 
actually cut releases if anything]

it’d be nice to have something more stable to regularly point to, but i don’t 
think we’re there yet.. (i pretty much cut pyzyre to work like this when it 
builds the czmq bindings[1], just updating the commits and sha1’s, which is a 
little more manual, but keeps things chugging along).

[1] https://github.com/wesyoung/pyzyre/blob/master/buildutils/czmq/fetch.py#L33

> On Nov 1, 2016, at 7:52 PM, Brian Knox  wrote:
> 
> No objections here - been using czmq off various commits off head for over a 
> year anyway

--
wes
wesyoung.me



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] CZMQ old v2 API proposal: deprecated -> retired

[Wes Young]

fwiw; what’s currently in czmq master *appears* to work OK with zmq-4.1-, i 
wanna say i have even tested it against zmq-4.2 (libzmq-master) w/o much issue, 
both not *extensively*, but enough to have some confidence in it.

so … +1 for pushing it further faster [if that means anything anyway].

> On Oct 28, 2016, at 1:56 PM, Luca Boccassi  wrote:
> 
> Comments, objections?

--
wes
wesyoung.me



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Just want to say hi

[Wes Young]

for sure. prob close in the next few weeks...

fwiw; something like:

$ pip install https://github.com/wesyoung/pyzyre/archive/master.zip

appears to work OK on linux (need higher versions of cython and libuuid), still 
working on pyczmq. has an appveyor.yml file in there so can start looking at 
windows builds, [they obvs break atm]. have a few chat examples i’m cleaning up 
too.

i added a pyzyre.utils lib in there too that leverages things like netifaces to 
help you figure out things like “give me an adapter and i’ll give you back the 
address” (for stuff like gossip…). helpers that make it easier to work with in 
python...

more to come..

> On Oct 14, 2016, at 8:06 AM, Kevin Sapper  wrote:
> 
> It would be really great if we could integrate this into our automatic 
> deployment. Whenever the pip deployment is ready let me know then we can 
> integrate it in zproject.

--
wes
wesyoung.me



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Just want to say hi

[Wes Young]

i started banging away sort of at this:

https://github.com/wesyoung/pyzyre
https://github.com/wesyoung/pyczmq

these leverage what pyzmq did in terms of “build the C stuff from source and 
embed the .so locally, use the generated c-bindings on top of that” (made some 
patches to zproject to load a local .so properly).

there’s still a ways to go; but idea being you could get czmq / zyre bindings 
from a pip command (testing that is about where i’m at..)

also; adds “pyczmq|pyzyre” into the mix as a module so we can build more 
“pythonic” abstractions on top czmq|zyre while still providing the low level 
stuff “as is” (you can still 'import czmq; ..’)

i’m also assuming by “package management” you’re meaning RPM|PPA, etc.. but 
wanted to throw in pip as well.

fwiw..

> On Oct 14, 2016, at 2:10 AM, Kevin Sapper  wrote:
> 
> - As you seem to know python. For our C projects we have binding generators 
> for python which work fine but the binding code is currently not deployed to 
> a package management system.
> See zproject [1] for the binding generator and czmq [2] as a example for the 
> generated bindings.
> 
> - A consensus implementation might be useful for zyre [3]. Probably as 
> another library on top of zyre.
> 

--
wes
wesyoung.me



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] czmq / zyre releases

[Wes Young]

ack. obs can hard-code commits into the build system(s) for the time being, 
just thinking about time-frames.

ty!

> On Oct 6, 2016, at 2:09 PM, Kevin Sapper  wrote:
> 
> we thought about it and came to the same conclusion, that we should wait 
> until libzmq 4.2 is released. Thanks to zproject releasing is complete 
> automated so no help needed ;) Though I would like to push to API of zyre to 
> stable before.

--
wes
wesyoung.me



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

[zeromq-dev] czmq / zyre releases

[Wes Young]

has anyone given any thought in cutting new releases of czmq and zyre ? i 
*think* they both work with 4.1, but there might be new features they take 
advantage of in 4.2 (i forget off hand), so if/when zeromq-4.2 is released, 
maybe a good time to cut new versions of those as well?

czmq 3.0.2 was released over a year ago
zyre 0.0.4 was released back in feb

[obviously willing to help out here- wanted to see if anyone else was thinking 
about it or there were other deps in the way..]
--
wes
wesyoung.me



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] pyzmq and libzqm (4.2?)

[Wes Young]

errr “for the bundled build”.


.. context.

> On Oct 5, 2016, at 11:27 AM, Wes Young <w...@barely3am.com> wrote:
> 
> looks like a few build changes (tweetnacl, etc)

--
wes
wesyoung.me



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

[zeromq-dev] pyzmq and libzqm (4.2?)

[Wes Young]

anyone started looking into building pyzmq against 
https://github.com/zeromq/libzmq [what looks like 4.2?]

i’m messing around with it; looks like a few build changes (tweetnacl, etc). 
didn’t see anything obvious in the issues list [i was gonna log one just to 
keep track if multiple people are looking at it before i started making PRs… ]

also; since there seems to be some lower level changes, any [preferred] 
thoughts on the best way to work-around those in the build system? easy as just 
checking for version?
--
wes
wesyoung.me



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Goodbye my friend

[Wes Young]

+1, and i’m guessing most of us had to re-read it a few times over the years 
just to grok it all. :)

[and then we learned about zproject]

> On Oct 4, 2016, at 1:20 PM, Doron Somech  wrote:
> 
> My first encounter with Pieter work was 2011, I read the zeromq guide,
> for the first time, I finished the book that night without going to
> sleep.
> I remember I thought that it change everything I knew about
> distributed systems, it was the best paper I read about software, and
> still is.

--
wes
wesyoung.me



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] czmq + draft mode

[Wes Young]

ack, ty!

> On Sep 29, 2016, at 3:17 PM, Kevin Sapper  wrote:
> 
> For your cross compile issue you could consider adding the build script to 
> zproject like I did for raspberry pi.

--
wes
wesyoung.me



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] czmq + draft mode

[Wes Young]

gah, i guess this is made up for in the src/Makefile.am

if ENABLE_DRAFTS

…

figures as i fire off the email… a bit confusing but i guess there’s probably 
not an easy way to get around it.

> On Sep 29, 2016, at 2:52 PM, Wes Young <w...@barely3am.com> wrote:
> 
> if API’s are in “draft” mode, would it be prudent to add:

--
wes
wesyoung.me



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

[zeromq-dev] czmq + draft mode

[Wes Young]

odd-ball question:

if API’s are in “draft” mode, would it be prudent to add:

#ifdef CZMQ_BUILD_DRAFT_API

…

#endif

around the .c files [1]?

configure.ac seems to obscure this problem by setting -enable-drafts=yes by 
default, but if you “try to take things into your own hands” [ie: w/o using 
configure, say for generating libs for cross-platform bindings], not setting 
the ‘CZMQ_BUILD_DRAFT_API’ var seems to make things fall apart.


[1] [i have zero problem pushing some PRs here, jw if there’s an opinion out 
there]
 https://github.com/zeromq/czmq/compare/master...wesyoung:master

--
wes
wesyoung.me



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] peer-to-peer communication using ZMQ

[Wes Young]

is this what you’re looking for?

https://github.com/zeromq/czmq/tree/master/bindings/jni

> On Aug 9, 2016, at 2:39 AM, Yoav Agami  wrote:
> 
> My application uses Side A (JAVA) -> Side B (c++) communication.
> I looked into it and it seems to support c++, but did not see Java bindings. 
> Does it support Java as well?
> If not, what would you recommend for this: Java part -> sends messages to C++ 
> part (that supports a timeout, that it will not be blocking)

--
wes
wesyoung.me



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] czmq python bindings and signals

[Wes Young]

[for search posterity]

i guess you can do something like this:

os.environ['ZSYS_SIGHANDLER'] = ‘false'

which is picked up by zsys_init when a socket or actor is init’d.

i think the real answer is still exposing more of zsys_* through zproc, but 
having trouble with some of the declarations through zproject (since we’re 
handing a zsys_handler_fn through the generated bindings, and not a basic type 
like int, char, etc..).

there are a few similar examples in the code (mainly with callbacks in 
constructors), but haven’t come across one that works, so will probably keep 
digging through those as time permits and see if i can’t conjure up a PR. seems 
like something minor, just need to find it.

> On Aug 1, 2016, at 2:00 PM, Wes Young <w...@barely3am.com> wrote:
> 
> my gut says exposing the zsys_* functions a bit more to the higher level 
> languages seems like the way to go as far as generated bindings are 
> concerned, but almost leads me to believe i’m missing something there too.. 
> (the java work-around is confusing with this argument..).

--
wes
wesyoung.me



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] How to disconnect a peer from ZMQ ROUTER socket?

[Wes Young]

+1

also:

https://github.com/zeromq/zyre/blob/055219523325cef4e87941e07abc39718d7350e4/src/zyre_node.c#L948

moving to a pattern where you’re actively tracking peers as part of “the loop” 
and forcefully expiring them when they’re un-responsive (active management) is 
probably more the way to go.

> On Aug 2, 2016, at 7:52 AM, Kevin Sapper  wrote:
> 
> Hi Dharani,
> 
> have a look how zyre handles peers:
> https://github.com/zeromq/zyre/blob/055219523325cef4e87941e07abc39718d7350e4/src/zyre_node.c#L555
> 
> //Kevin
> 
> 
> 
> 2016-08-02 11:37 GMT+00:00 dharani kumar :
> Hi,
> I have a vpn network where the zmq router is installed on node with static ip 
> and all peers are installed on nodes with dynamic ip which means the ip will 
> change every time the vpn connection is made. If a peer node unfortunately 
> disconnects from the vpn network, the router wont be aware of this 
> disconnected peer. If the same peer reconnect to vpn but unfortunately gets a 
> different ip, it won't able to connect to router with same identity but 
> different ip.
> 
> I can write a ping-pong code to detect dead peer but how to delete the dead 
> peer from router socket registry so that it allows new connection for the 
> same identity but from a different ip?
> 
> Regards,
> Dharani kumar
> 
> 
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> 
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev

--
wes
wesyoung.me



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] How to send binary and text massage in one massage

[Wes Young]

seems like you could just [compress and/or] base64 encode the entire thing 
before it hits the zmq stack and de-combobulate it on the other end, then the 
multi-messaging should be easier(?). that way you're just handing a string to 
the zmq stack and leaving the heavy lifting to your application.

On Jan 10, 2013, at 3:23 AM, Matias Guijarro wrote:

 Maybe the easiest is to keep the xml format for messages,
 and to encode the binary file into base64 for example.
 
 Or you can maybe use multi-part messages of zmq, first part
 being xml and second (optional ?) part a binary chunk
 corresponding to your file.

--
Wes
wesyoung.me



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] Titanic SP with encrypted data transfer

[Wes Young]

ugh,

this has been on my list for some time, slowly moving up the priority chain... 
(current target is mid-spring)

https://github.com/wesyoung/libzmq

if you wanna port it up the 3x tree and fiddle with it a bit. haven't touched 
it in a few months, and even then, only got it to compile.

could someone post this to the encryption doc as a reference? i can't due to 
low karma.. :)

On Dec 14, 2012, at 4:52 AM, Jovan Kostovski wrote:

 Thank you very much for the answer Pieter,
 
 On Fri, Dec 14, 2012 at 12:23 AM, Pieter Hintjens p...@imatix.com wrote:
 On Thu, Dec 13, 2012 at 11:42 PM, Jovan Kostovski chomb...@gmail.com wrote:
 
 I know that ZeroMQ supports TLS
 shared keys encryption...
 
 It doesn't, yet, unfortunately.
 
 Hm... I know that ZMQ does not support it by it self,but I saw some
 example[1] which use TLS shared key encryption, so I wanted now what
 are the options...
 
 If you need encryption, you will need to either do it at a lower layer
 (VPN)
 If I use VPN it won't affect the the ZMQ sockets and messages, It
 would just be a ZMQ communication through a secure channel, right.
 
 You can also encrypt per message, using pre-shared keys, which is the
 least nasty option IMO.
 
 I think I'll go for this solution because it does not affect the ZMQ
 messaging layer and it would be easy just to encrypt the message
 payload (the message bodies)
 
 I do hope we find a better general solution at some stage; you are not
 the only person who hits this.
 
 Are there any ideas how to support this except the once on
 http://www.zeromq.org/topics:encryption ?
 I'm willing to help in the development
 
 
 BR, Jovan
 
 References:
 
 [1] https://github.com/ianbarber/TLSZMQ
 ___
 zeromq-dev mailing list
 zeromq-dev@lists.zeromq.org
 http://lists.zeromq.org/mailman/listinfo/zeromq-dev

--
Wes
wesyoung.me



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] ZMQ and TLS ( again )

[Wes Young]

 I rather prefer the integrated approach Wes Yuong used through
 zmq_setsockopt ( socket, ZMQ_TLS, true, 5 ) as it is easier to use,
 better integrated into the ZeroMQ API, and overall much cleaner from a
 users point of view.

:)

 What are the chances to integrate this into the latest ZeroMQ code base ?
 It seems to me that the impact would be minimal and the benefits would be
 outstanding.

fwiw: [at the time] i was waiting for 3.x to settle down a bit before diving 
back into this.

 If the documentation points out exactly when and how to use TLS, then I
 think the concerns about unsupported communication types can be mitigated.
 Also if this can be enabled during compile time through a switch to the
 configure script it would not interfere with the other core features.
 
 My last point is that the changes which I saw on git seem minimal, which
 should be good news to any one concerned about code-bloat.

we were trying to do it as a compile time argument for starters, and what we 
started figuring out (to be tested) after reading through [just about all of] 
libgnutls is that we might even be able to get away with anonymous TLS at the 
zmq level and leave the Identity / auth up to the higher levels of the 
protocol itself (being implemented in our testing as protobuf atm).

 Encryption is or should be an inherent capability of sockets and socket
 libraries in this day and age.

while i don't disagree, and i think the solution will be a rather elegant one 
(i hope :x); it's a tough problem to solve correctly. some of which is 
determined on how the low-level stack was/is implemented (the way libzmq works 
and the way gnutls works)…

 Please consider adding TLS encryption to ZeroMQ, if only as alpha for now.

the original branch i wrote should be considered alpha in and of itself. i 
hadn't gotten much feedback other than that's a neat idea yet. this kind of 
crypto (at this level) could prove to make zmq unstable, which is why even in 
the branch you have to add it at compile time as a ./configure flag.

crypto is hard; gnutls is worse; and if you do it wrong you're going to screw a 
*lot* of people in the process. which is why i'm guessing i haven't gotten a 
lot of other eyeballs on it just yet either :)

either way, we should have more traction on our end for this come early fall or 
so. we'll be getting to a point in our project where we'll start testing these 
kinda links at scale… one way or the other it's on our list of things where 
it's a requirement to be solved.

cheers,

--
Wes
wesyoung.me
collectiveintel.net



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] v3.1 and pre-built devices

[Wes Young]

https://github.com/zeromq/libzfl

?

looks like zdevice.c was pushed to libzfl ?

On Mar 11, 2012, at 3:12 PM, Jon Dyte wrote:

 The project moved here, but I'm not sure if it's completely up to date
 https://github.com/imatix/zdevices
 
 FWIW most of the devices are very simple and it's fairly easy to 
 roll-yr-own.

--
Wes
claimid.com/wesyoung



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] suggestion for two more Guide examples

[Wes Young]

fwiw:

sometime within the next six months or so; we[1] should have a decent set of 
examples in the security space demo'ing this functionality. Right now we're 
building google protobufs and thrift bufs for a few security protocols (IDMEF, 
IODEF, ICSG and MAEC). This is what sort of drove the previous libzfl and 
device discussion. I would imagine building some generic code to handle these 
serialization cases being built into the devices (libzfl for instance). Same 
with some of the certificate based crypto code.. I know the ZeroMQ-perl does 
something neat with serialization hooks already, just needs some better hooks 
at the C level (unless i'm missing them…).

Too many people (in the security space) gave up on these protocols (mainly IETF 
RFC's) due to their complexity. We're working (via the NSF) to capitalize on 
their international standard-ness and lower the barrier to entry so they're 
usable at faster data-rates (rather than everyone defining their own key-pair 
'protocol') and then not being able to exchange data in the international 
security space.

[1] https://github.com/collectiveintel

On Feb 27, 2012, at 4:30 PM, Pieter Hintjens wrote:

 Actually this is a really nice idea and could lend itself to a
 0MQ-specific serialization layer.

--
Wes
claimid.com/wesyoung

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] suggestion for two more Guide examples

[Wes Young]

interestingly enough, I just came across:

https://github.com/apache/thrift/tree/trunk/contrib/zeromq

if you're looking for other examples…

On Feb 27, 2012, at 4:30 PM, Pieter Hintjens wrote:

 Perhaps including the
 zeromq-specific notion that a Message is a *sequence* of blobs, with an
 example that sends a metadata struct + zero-copy send of a buffer.
 
 Actually this is a really nice idea and could lend itself to a
 0MQ-specific serialization layer.

--
Wes
claimid.com/wesyoung

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] TLS (bare with me)

[Wes Young]

On 2012-02-24, at 5:12 PM, john skaller wrote:

 So I am guessing various LGPL licences (without linking exemption).

haven't gotten to the licensing issues yet (if any between gnutls and libzmq). 
Whatever I publish is usually BSD so you can do whatever your want with it.

 Depends on? libnettle? lbgmp?

another reason i went with 2.8.6 was to avoid libnettle (in exchange for 
getting it to compile on debian squeeze first). nettle didn't make an 
appearance till gnutls 2.10 or 3? I do have libgmp installed, didn't check to 
see if it was libgmp was a dep or not 
(http://packages.debian.org/source/squeeze/gnutls26)

down the road, once we figure this out, 3.x starts to support DTLS (tls+udp, 
etc..) which (i think) will make the async io stuff even faster and more 
flexible.

i have a design question (purely out of curiosity) though:

what was the reasoning for doing libzmq in C++ rather than C?. Esp when we're 
wrapping a C api around it anyway? I understand OO programming can be easier 
sometimes, etc.. just curious if there was a specific design decision that went 
into it or that (that' i'm just missing) it's just the way it evolved..

the lib is def very well documented and written, it's just a little funny (also 
with all the .hpp's mixed with the .cpp's instead of using things like an 
include/ directory, etc… I'm guessing an artifact of visual studio?).

again, just curious.

--
Wes
claimid.com/wesyoung



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] TLS (bare with me)

[Wes Young]

https://github.com/wesyoung/libzmq

so i've got anon[1] TLS working (sort of freakishly hacked up) against a fork 
of the current trunk. It's very poorly written, needs a lot of re-factoring, 
testing, etc etc.. Just sort of mocked it up best I could (been knee deep in 
perl for the last 4 years.. had to re-wire myself to write in $C).

it's really shitty code, so bare with me, but for those willing to take the 
plunge and review:

tests/tls_hwserver.cpp
tests/tls_hwclient.cpp
tests/test_tls.cpp

all compile and appear to work (although I haven't really looked at the packets 
too much, just the debugging output of gnutls-2.8.6, which makes me believe 
it's getting encrypted :)).

./configure --with-tls 

will get you started. The bulk of the change is here:

https://github.com/wesyoung/libzmq/commit/cdc95d04da25609d40754714ce0d73447820fd9f

although a few commits after that clean up some of the test stuff. I was trying 
to set it up in a way where all the crypto stuff could be done at the 
application layer and minimal hooks could be implemented at the library layer 
using zmq_setsockopt, but with the const *void there, and the fact that C++ 
hates sending pointers to functions around too much (call-backs), it made for a 
bunch of code in the library itself. I'm sure there are decent ways to pull it 
off, just haven't figured it all out yet.

Ideally, you'd be able to pass the socket a gnutls_session_t after dealing with 
all your security stuff (anon or x509's, etc) up in the app, then just #ifdef 
ZMQ_HAVE_TLS the send/recv functions at the lower level, but I dunno that it's 
gonna be possible in C++ based on the way the gnutls C api is laid out (haven't 
touched it's C++ bindings).

Please make sure you've had a few beers before you test, it makes the crypto 
code simpler to read.

The TLS doc is 3.0.13, the bindings were dev'd against gnutls-2.8.6 (debian 
squeeze). The api's change abit  2.10 or so, esp when it comes to async IO 
callback operations in gnutls.. so if you're using anything  2.8.6 it might 
not work at all.

feedback welcome. it's enough code to make me wanna break out into another set 
of libraries (with simpler hooks into libzmq), but for prototype purposes, it … 
compiles. I make no claim or warranty that you won't get ow3nd by using it… :x

[1] 
http://www.gnu.org/software/gnutls/manual/gnutls.html#Simple-client-example-with-anonymous-authentication

On Jan 24, 2012, at 4:42 PM, Wes Young wrote:

 Pardon the seemingly newb-ish question,
 
 I read through:
 
 http://thread.gmane.org/gmane.network.zeromq.devel/4602/focus=4640
 
 and the TLS bits you'll find here:
 
 http://travlr.github.com/zmqirclog/110402.html#msg-77
 
 and 
 
 http://www.zeromq.org/search:site/q/encryption
 
 i'm digging through the code (and maybe i'm missing it), was any work 
 actually done in the realm of tls://. There are a lot of reasons (in the 
 realm of federated networks) why this functionality would be useful. 
 PreludeIDS did some similar stuff with the IDMEF messaging protocol, handled 
 the TLS exchanges, signing, etc.. I'm looking to port this functionality into 
 either ZeroMQ, or an extension or..
 
 just wanna make sure i'm not re-inventing the wheel somewhere.. the threads 
 seem to die out late 2010 and I don't see anything obvious in the change-log 
 (yet?).
 
 .. if it's already done, or being done, could someone point me in the right 
 direction? if not, i'll be hacking it out (via gnu-tls probably) as an addon 
 or something over the next few months.
 
 I understand all the reasoning for doing this at the message stack, etc.. and 
 I see SALT doing some of this (in python, at the message level) just seeing 
 where this thread left off before I dive in.
 
 thanks,
 - --
 Wes
 claimid.com/wesyoung
 

--
Wes
claimid.com/wesyoung

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] RFC:5/ZDCF work

[Wes Young]

lol:

To make the C examples easier to write and read, I've taken the hash and list 
container classes from the ZFL project, and renamed them as [zlist and zhash, 
as we did with zmsg. In any modern language you can of course use built-in 
containers.

yea, i literally *just* got to that point :)

I cleaned zfl up a little yesterday (in a fork). Only really needed to remove 
zthread since it's in czmq, other than that it compiled a-OK. I think I get 
where you're going, and now that I read through the majordomo stuff, makes 
sense. I could see that library splitting out into a few other minors (config, 
devices, protocols, etc..), but dunno how it'll look till i finish the guide 
and the tls bindings (started hacking around with the internal socket FD calls 
and the gnutls wrapper functions a bit).

there are some weird spots in the guide that are a little dated (references to 
zlist and zhash to zfl, etc) fwiw.

On 2012-02-11, at 1:56 PM, Pieter Hintjens wrote:

 Yes, and zdevices. zfl needs cleaning up because a lot of the core was
 refactored into CZMQ. But I think it's sensible, a richer library on
 top of CZMQ that offers what services need. There are a few things I'd
 like to add, like UDP discovery.

--
Wes
claimid.com/wesyoung



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

[zeromq-dev] RFC:5/ZDCF work

[Wes Young]

ref: http://rfc.zeromq.org/spec:5
 http://thread.gmane.org/gmane.network.zeromq.devel/3391/focus=3556

The ZeroMQ Device Configuration File (ZDCF) specifies a standard language for 
configuring 0MQ devices. It provides information to configure a 0MQ context, 
and a set of 0MQ sockets. This specification aims to make it easier to build, 
share, and reuse 0MQ devices and build systems for device administration.

has any real code been written around this yet? I followed some of the 
'examples' links (to github) in the thread but they were defunct now.

if not, if we were to build in libconfig support to read these types of files, 
pointers as to where it should go in the stack would be helpful… (still 
digesting zmq's contribution process). I'd rather they were in the libzmq or 
even libczmq stack rather than the application stack.. Given that ZDCF was mean 
to be json/xml/.. it can probably be pluggable too.

Let me know if i'm missing an obvious pointer here...
--
Wes
claimid.com/wesyoung

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Re: [zeromq-dev] RFC:5/ZDCF work

[Wes Young]

aye, I did some more digging between v2 and v3.1, found those bits (and more 
around why zloop is the way it is). The project i'm writing sorta has a low 
level C requirement (for perf reasons), and what I need was a way to configure 
the sockets sort of on the fly (type, addresses, TLS information … that I need 
to build in, etc..).

shouldn't be hard to do and contribute back, wanted to make sure it wasn't 
already done / not done for a specific reason. Sounds like the high level 
languages sort of took care of the basics, diminishing the need (that and most 
other stuff is easy to take care of at the high language level).

will mock something up using libconfig and post back, see if we can figure out 
where it should go.

On Feb 9, 2012, at 8:48 AM, Ian Barber wrote:

 They're just not packed in zeromq - they're not gone conceptually, and in 
 fact many of the bindings ship with device code built in (including more 
 complex ones, I believe python has a monitored queue for example). I don't 
 believe that there has been anything further on this project - most simple 
 devices tend to map to the basic repeater, and more complex ones have been 
 bespoke thus far. Project still has merit though, so feel free to contribute 
 something if you do write some code around it!

--
Wes
claimid.com/wesyoung

___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

[zeromq-dev] TLS (bare with me)

[Wes Young]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Pardon the seemingly newb-ish question,

I read through:

http://thread.gmane.org/gmane.network.zeromq.devel/4602/focus=4640

and the TLS bits you'll find here:

http://travlr.github.com/zmqirclog/110402.html#msg-77

and 

http://www.zeromq.org/search:site/q/encryption

i'm digging through the code (and maybe i'm missing it), was any work actually 
done in the realm of tls://. There are a lot of reasons (in the realm of 
federated networks) why this functionality would be useful. PreludeIDS did some 
similar stuff with the IDMEF messaging protocol, handled the TLS exchanges, 
signing, etc.. I'm looking to port this functionality into either ZeroMQ, or an 
extension or..

just wanna make sure i'm not re-inventing the wheel somewhere.. the threads 
seem to die out late 2010 and I don't see anything obvious in the change-log 
(yet?).

.. if it's already done, or being done, could someone point me in the right 
direction? if not, i'll be hacking it out (via gnu-tls probably) as an addon or 
something over the next few months.

I understand all the reasoning for doing this at the message stack, etc.. and I 
see SALT doing some of this (in python, at the message level) just seeing where 
this thread left off before I dive in.

thanks,
- --
Wes
claimid.com/wesyoung

-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.16 (Darwin)

iEYEARECAAYFAk8fJdEACgkQrvVOnTJLGyFltgCeM6Ci/X7YdHn31wWL4NZVcDAj
6owAniH7BteS7dBGcUERRlsFd9EHVi6r
=czub
-END PGP SIGNATURE-
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev