[zeromq-dev] ZMQ_FD and inproc:// socket

[Arnaud Kapp]

Hello,

I'm using zmqpp in my project, and I have a special case where I need to
integrate
with boost::asio (this is what azmq does, but for now I just need it once,
so I don't want
to switch libraries).

The idea was to rely on ZMQ_FD and add the corresponding FD to ASIO's event
loop.
However, I've found that async_read_some() wasn't triggered. It turns out
it's likely an issue
in libzmq: https://github.com/zeromq/libzmq/issues/1434

After taking a quick look at AZQM it seems it's also using ZMQ_FD.
Can anyone tell me what's the trick to get them to work?

Thanks,

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

Re: [zeromq-dev] ZMQPP and metadata in ZAP reply

[Arnaud Kapp]

Hey David,

Glad to have confirmation that this works :)

Regarding your follow-up question, I do not know.

I can however offer a potential workaround. I don't like it very much tho.
We know that the ZAP handler bind on "inproc://". Inproc is context
specific.
This means that if you have 2 different zeroMQ contexts, you can have
2 different handlers. You could then group up socket by type in a context,
and have
different handler for the 2 contexts.

Now, I said I don't like that very much. I don't know the impact (on
performance) of having multiple context.
I would guess it's negligible though. Depending on how your code works, it
may be annoying for you
to keep reference to 2 (or more) contexts.

I do think that a patch to libzmq improving the behavior and exposing more
informations has a good
chance to be accepted.

On Sun, May 8, 2016 at 10:50 PM, David Jelenc 
wrote:

> Hi,
>
> to anyone who may also want to encode metadata to ZAP replies (to be later
> used--for instance--for authorization purposes) -- Arnaud's suggestion
> works great.
>
> (The idea is for the ZAP handler to write authorization data into metadata
> field which is later available on every message coming from the
> authenticated client in the form of a message property.)
>
> I have a follow up question that is more ZAP related: besides the fields
> defined in ZRFC27, is there any other client data I can access? Like the
> port to which the client connected or the type of client's socket?
>
> My ZAP handler authenticates several sockets and I'd like to have separate
> logic in my ZAP handler depending on the socket type. (I'm asking about the
> port number, because I can infer the socket type from it.)
>
> Best,
> David
>
> On 29. 04. 2016 23:25, Arnaud Kapp wrote:
>
>> Hello David,
>>
>>  > I sense, this part has to be addressed in libzmq and not in zmqpp,
>> but I’m not sure where.
>>
>> In theory libzmq supports your use case. You'd have to write your own
>> ZAP handler manualy and return your metada as part of the ZAP reply (as
>> specified in ZRFC27)
>> You cannot use zmqpp::auth for this, it's not flexible enough.
>>
>>  > However, I see no way for accessing the additional parts of the ZAP
>> reply on my server.
>>
>> Your "listofactions" metadata property would be available on any
>> messages from the matching client.
>> To retrieve a metadata/property from a message with zmqpp you can use:
>> msg.get_property("pname", out);
>>
>> I know this works for the "Identity" property. Unless libzmq doesn't
>> implement it for generic properties, it should work.
>> Let us know how you fare.
>>
>> On Fri, Apr 29, 2016 at 3:39 PM, David Jelenc
>> mailto:david.jel...@fri.uni-lj.si>> wrote:
>>
>> According to http://rfc.zeromq.org/spec:27, the ZAP reply contains
>> several fields, including the metadata filed that can be used to
>> store additional data regarding the authenticating clients.
>>
>> I’d like to use this filed to store some authorization data: the
>> idea is that, using ZAP, my server queries an AAA server that either
>> accepts or rejects the the connecting client. If the client is
>> accepted, the AAA also provides a list of actions the accepted
>> client is allowed to perform. I’d like to store this actions in the
>> metadata field of the ZAP reply.
>>
>> I’m using zmqpp C++ bindings, where the metadata is currently
>> hardcoded to be empty
>> (
>> https://github.com/zeromq/zmqpp/blob/develop/src/zmqpp/zap_request.cpp#L83
>> ).
>> However, this is easily addressed.
>>
>> My main concern is now on the server side: where and how do I
>> process this metadata?
>>
>> The API is such that if the ZAP reply contains status code 200 and a
>> OK message, the client is allowed to connect. However, I see no way
>> for accessing the additional parts of the ZAP reply on my server.
>>
>> I sense, this part has to be addressed in libzmq and not in zmqpp,
>> but I’m not sure where.
>>
>> Any help would be greatly appreciated.
>>
>> Best,
>> David
>> ___
>> zeromq-dev mailing list
>> zeromq-dev@lists.zeromq.org <mailto:zeromq-dev@lists.zeromq.org>
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
>>
>>
>>
>> --
>> Kapp Arnaud - Xaqq
>>
>>
>> ___
>> 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
>



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

Re: [zeromq-dev] ZMQPP and metadata in ZAP reply

[Arnaud Kapp]

Hello David,

> I sense, this part has to be addressed in libzmq and not in zmqpp, but
I’m not sure where.

In theory libzmq supports your use case. You'd have to write your own ZAP
handler manualy and return your metada as part of the ZAP reply (as
specified in ZRFC27)
You cannot use zmqpp::auth for this, it's not flexible enough.

> However, I see no way for accessing the additional parts of the ZAP reply
on my server.

Your "listofactions" metadata property would be available on any messages
from the matching client.
To retrieve a metadata/property from a message with zmqpp you can use:
msg.get_property("pname", out);

I know this works for the "Identity" property. Unless libzmq doesn't
implement it for generic properties, it should work.
Let us know how you fare.

On Fri, Apr 29, 2016 at 3:39 PM, David Jelenc 
wrote:

> According to http://rfc.zeromq.org/spec:27, the ZAP reply contains
> several fields, including the metadata filed that can be used to store
> additional data regarding the authenticating clients.
>
> I’d like to use this filed to store some authorization data: the idea is
> that, using ZAP, my server queries an AAA server that either accepts or
> rejects the the connecting client. If the client is accepted, the AAA also
> provides a list of actions the accepted client is allowed to perform. I’d
> like to store this actions in the metadata field of the ZAP reply.
>
> I’m using zmqpp C++ bindings, where the metadata is currently hardcoded to
> be empty (
> https://github.com/zeromq/zmqpp/blob/develop/src/zmqpp/zap_request.cpp#L83).
> However, this is easily addressed.
>
> My main concern is now on the server side: where and how do I process this
> metadata?
>
> The API is such that if the ZAP reply contains status code 200 and a OK
> message, the client is allowed to connect. However, I see no way for
> accessing the additional parts of the ZAP reply on my server.
>
> I sense, this part has to be addressed in libzmq and not in zmqpp, but I’m
> not sure where.
>
> Any help would be greatly appreciated.
>
> Best,
> David
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev




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

Re: [zeromq-dev] ZeroMQ MPL Licensing plans?

[Arnaud Kapp]

Hello,

You'd better wait for Peter to answer as he'd provide a more authoritative
answer.

As far as I know we're not even trying to move libzmq to MPLv2 because the
codebase is rather old and it'd be hard to track down every contributor.
New Zeromq-related projects (bindings, etc) are using MPL, and some related
project have been moved to MPL: zmqpp for example -- however the number
of contributor was around 20 people so it was much easier to contact
everyone.

Not sure if it helps, but we provide the "link exception" that many people
using the LGPL also provide.

On Thu, Jan 28, 2016 at 6:12 PM, Sam Ruby  wrote:

> I'm not certain where to best ask this question.  Please let me know
> if it would be better addressed elsewhere.
>
> At the Apache Software Foundation we have an incubating project (named
> Toree[1]) that has a dependency on Zeromq.  LGPL is problematic for
> us[2], probably for the same reasons that you are considering moving
> to MPL[3].
>
> What is the status and plans of your move to MPLv2?
>
> - Sam Ruby
>
> [1] https://wiki.apache.org/incubator/ToriiProposal
> [2] http://www.apache.org/legal/resolved.html
> [3] http://zeromq.org/area:licensing
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>



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

Re: [zeromq-dev] RPC over DEALER-ROUTER conection (async client/server)

[Arnaud Kapp]

Hello,

I agree with Doron here. Option is imo better and easier to implement.

+ Let the client generate a request idenfier (numbered, uuid, whatever
you prefer) and prepend it to request content.
+ The server simply copy that frame and prepend it to the response.
+ The client perform the match.



On Fri, Dec 18, 2015 at 11:09 AM, Doron Somech  wrote:

> I disagree, I think the first option is the right one, and much faster
> (you don't have to create sockets).
>
> The server (router) doesn't really need to understand it, only use it when
> reply.
>
> So the first frame is the routing id (aka identity), make the next frame
> the request id, now when the router reply it has to push the routing id and
> the request id before the reply.
>
> Another way to do it is to create inproc socket for each request (this is
> also expensive) like so:
>
> REQ connect to inproc
>
> PROXY
>ROUTER bind on inproc
>DEALER connect to server
>
> REP - bind to server address.
>
> With this you have the request id automatically inside the message frames
> by zeromq sockets (you have two routing ids pushed to the message frames,
> first one of the REQ socket and second one of the DEALER socket).
>
> Anyway just do the zeromq socket logic without using the complex chaining.
>
>
>
>
> On Fri, Dec 18, 2015 at 11:55 AM, cibercitizen1 
> wrote:
>
>>
>> Sorry if here is not the right place to ask this.
>>
>> I'm considering to implement simple RPC over
>> a DEALER-ROUTER connection. Thus, I'm facing
>> the obvious problem of matching the answers from the
>> router side with the corresponding requests by the
>> dealer side.
>>
>> Options considered:
>>
>> 1. number each request. Cons: the server (router side) must be
>>aware of this, and participate in the strategy.
>>
>> 2. use a separate (and dedicated) dealer socket for each RPC
>> call. (Using a pool of reusable open connections so as to
>> save time). Pros: this is transparent to the server.
>>
>> Is there any other option?
>>
>> Am I right that option 2 is the best?
>>
>> Thank you for any comment.
>>
>> ___
>> 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
>
>


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

Re: [zeromq-dev] ZeroMQ License

[Arnaud Kapp]

Hello,

I've never used the installer, but libzmq is indeed distributed under the LGPL.

See https://github.com/zeromq/libzmq#license or http://zeromq.org/area:faq#toc4

On Thu, Oct 15, 2015 at 10:57 PM, Peter Ritter  wrote:
>
>
> Hello
>
> I got a quick question about the ZeroMQ license. I was under the impression
> that ZeroMQ is distributed under the LGPL license (GNU Lesser General Public
> License). However, I just used the Windows installer (64Bit) and it pretty
> much looked like I had to agree to the GPL (GNU General Public License). I
> ran the installer twice just to be sure. I didn't see anything about LGPL.
> Maybe I'm imagining things, but I thought I'd ask nonetheless.
> Thanks in advance.
> Peter
>
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>



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

Re: [zeromq-dev] python3 2 threads and PAIR sockets, when to close?

[Arnaud Kapp]

> For a PAIR socket, between 2 threads, does the binder need to bind before the 
> connector connects?

Depends on libzmq's version. With current trunk it works. I believe it
also works in 4.1. Not sure though.

> Can the sender close the socket as soon as they have send_pyobj, and the 
> other thread would receive anyways?

I don't know if send_pyobj() is special (I don't know much about GC /
refcounting in Python), but I believe
it should be alright.

On Fri, Sep 18, 2015 at 4:13 PM, MM  wrote:
>
>
> On 3 September 2015 at 15:58, MM  wrote:
>>
>> hello
>>
>> I have:
>>
>> def thread1():
>>   s = context.socket(zmq.PAIR)
>>   s.bind('inproc://name')
>>   s.send_pyobj( dictionary )
>>   ### That's all I need to do , can I close s here?
>>   while True:
>># stay alive forever
>>
>> def thread2():
>>s = context.socket(zmq.PAIR)
>>s.connect('inproc://name')
>>dx = s.recv_pyobj()
>>while True:
>># stay alive forever
>>
>> def main():
>>   Thread(thread1..).start()
>>time.sleep(5) #5secs
>>   Thread(thread2..).start()
>>   #wait for signals
>>
>>
>> thread1 is the parent one, proceeds independently.
>> thread2 can only proceed once it got the dictionary from thread1
>>
>> 1. do I need the sleep(5) in the main thread to ensure thread1 bind
>> happens before thread2 connect?
>> 2. can I close s in thread1 as soon as I send the dictionary?
>>
>> Thanks,
>
>
> Apologies if the answers to these questions are in the manual, I couldn't
> see them.
>
> For a PAIR socket, between 2 threads, does the binder need to bind before
> the connector connects?
> Can the sender close the socket as soon as they have send_pyobj, and the
> other thread would receive anyways?
>
> Regards,
>
>
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>



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

Re: [zeromq-dev] Cookbook repository

[Arnaud Kapp]

Hello everyone,

This is a good idea indeed.
Regarding licensing we want something very open. I suppose some people
may copy-paste
some code into their program.

I wonder if we should build the thing as a website generated from
source (something like sphinx)
to host-it in a user-friendly using gh-pages or something.
Or if simply having a repository with a few README is enough.



On Tue, Sep 8, 2015 at 11:04 PM, Pieter Hintjens  wrote:
> For licensing, MPLv2 is an issue as many people want to reuse these
> recipes in closed apps... for the Guide we went for an MIT/X11 license
> instead.
>
> On Tue, Sep 8, 2015 at 9:47 AM, Johan Philips  
> wrote:
>>
>>> On 08 Sep 2015, at 14:19, Pieter Hintjens  wrote:
>>>
>>> First recipe can be Hello World :-) I suggest we make the whole repo
>>> with pull requests as always. So all we need to get started is a new
>>> repo, a link to RFC 22, a license for code.
>>>
>>> I think we can make a load of different Hello World recipes, for
>>> different socket types.
>>
>> Interesting initiative! We have been writing an (academic) publication with 
>> robotics use cases for many of the zeromq patterns, they might also fit in a 
>> more generic context / general domain.
>>
>> Johan
>>
>>
>>>
>>> On Tue, Sep 8, 2015 at 4:32 AM, Doron Somech  wrote:
 Happy to hear the good responses. I have limited access to internet and
 computer in the coming month so I won't be able to contribute much. But 
 will
 contribute afterwards. Looking forward to see the first recipe...

 This is a fantastic idea...

 The Guide is old, and the process predates C4. It's time to build a
 new repository of examples IMO.

 We can write recipes clearly, as problem statements, and then show how
 to make them in all our languages and bindings.



 On Mon, Sep 7, 2015 at 5:28 PM, Brian Knox  wrote:
> I think a ZeroMQ cookbook sounds like a neat idea.  I'd happily contribute
> some examples for the GoCZMQ bindings - it would be a fun project to
> implement some of the patterns using them.
>
> Tying each pattern to a problem statement would be very much in the spirit
> of ZeroMQ development methodology itself.
>
> On Mon, Sep 7, 2015 at 10:03 AM, Doron Somech  wrote:
>>
>> Hi All,
>>
>> Problem1: Find the right zeromq pattern is sometime complicated, not all
>> patterns are documented and searching through different blog posts or
>> mail
>> archives is hard.
>>
>> Problem2: I have a problem and I want to know if another user in the
>> community already had it and found a simple solution. Right now I have to
>> ask on the mailing list and wait for somebody to response.
>>
>> So zeromq guide have some patterns documented but I think we can do more.
>> My idea is to create cookbook repository, so each pattern has
>> documentation
>> (what is the problem this pattern is solving and how to use) and
>> implementation in at least one language.
>>
>> It will be easier to direct people to a specific pattern in the cookbook
>> repository and also share the different problems and solutions we all
>> use.
>>
>> What do you think?
>>
>>
>>
>> ___
>> 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
>
 ___
 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

>>> ___
>>> 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
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev



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

Re: [zeromq-dev] Any way to get key used for router connection

[Arnaud Kapp]

Hello,

There is an easy way to do what you want, but it isn't obvious at
first. ZAP is actually allowed to set a "User-Id" meta-data property
for all messages from a connection.
This means that your ZAP code can chose to set the curve key as the
user-id for the connection.

To set a user-id property from the ZAP handling code, you simply have
to specify it in the ZAP reply you write. You will then be able to
retrieve the user-id (which would be the curve public key, if you
chose so) by doing something like zmq_msg_gets(msg, "User-Id");

Hope this helps.

On Mon, Aug 17, 2015 at 4:03 PM, Charles West  wrote:
> Hey Pieter,
>
> Thank you for taking the time to respond.
>
> I have read both of the blog entries, the source for zauth and based my code
> off of the specification for the ZAP protocol.  The closest/most relevant
> documentation I saw was your discussion with Stephen Eley in the "Confirm
> authentication and retrieve metadata?" thread.
>
> If I may ask, is there some obvious way that I am missing to get the key
> associated with a connection with a Router in ZMQ 4.0.4 (the zmq available
> in the Ubuntu repositories)?  Alternatively, is there any good way to figure
> out which router connection a ZAP request refers to?
>
>
> I apologize if I have missed something obvious, but the examples I have seen
> seem focused on go/no go authentication rather than keys with different
> levels of permissions.
>
> Thanks,
> Charlie West
>
>
> On Mon, Aug 17, 2015 at 6:35 AM, Pieter Hintjens  wrote:
>>
>> Have you studied the security examples I wrote?
>>
>> - read http://hintjens.com/blog:48 and http://hintjens.com/blog:49
>> - don't use ROUTER identity, the field is really a routing key and has
>> nothing to do with peer identity
>> - look at how CZMQ's zauth works, and look at the RFC for the ZAP
>> protocol (http://rfc.zeromq.org/spec:27)
>>
>> On Mon, Aug 17, 2015 at 5:43 AM, Charles West  wrote:
>> > Hello!
>> >
>> > I'm building the second version of a open source differential GPS
>> > sharing
>> > software (pylongps.com).  I've run into a bit of a snag though.
>> >
>> > Does anyone know of a good way to get the key associated with a CURVE
>> > router
>> > connection?  ZAP authentication can check if a key is on the whitelist,
>> > but
>> > it doesn't appear to provide more than a go/no go.  I need to be able to
>> > check the key associated with a specific ROUTER connection so that I can
>> > limit what the owner of a particular connection key can do (people with
>> > one
>> > key can't pretend to be someone else).
>> >
>> > My original idea was to use the ZMQ_IDENTITY field to set the connection
>> > ID
>> > to a superset of the connection key, then just have the ZAP handler
>> > verify
>> > the connection ID contained the key at the beginning.  Further ID
>> > processing
>> > would then be done via the connection ID at the router socket.  However,
>> > the
>> > ZMQ_IDENTITY set does not show up in the ZAP messages, so this isn't
>> > possible.  Further reading of the mailing list indicates that the
>> > ZMQ_IDENTITY isn't suppose to propagate like that anyway.
>> >
>> > The brute force solution would be to force a authentication exchange
>> > using a
>> > signing key and a nonce at the router (router sends nonce, client signs
>> > or
>> > encrypts it and sends it back).  Thats basically doing a whole handshake
>> > on
>> > top of the ZMQ_CURVE protocol, which seems rather overkill.
>> >
>> > Does anyone know of a better approach?
>> >
>> > Thanks,
>> > Charlie West
>> >
>> > ___
>> > 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
>
>
>
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>



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

Re: [zeromq-dev] ZeroMQ & Raspberry Pi (Debian)

[Arnaud Kapp]

I don't know about your particular problem but I can confirm that
building libzmq from source works well.

On Sat, Aug 15, 2015 at 12:10 AM, KIU Shueng Chuan  wrote:
> Fwiw, I recently tried zeromq 4.1.2 with raspberry pi B. How about compiling
> zeromq from source and running the test suite?
>
> One test failed intermittently but that was due to the slowness of the pi, I
> think.
>
> On 15 Aug 2015 00:00, "Kelly Beard"  wrote:
>>
>> I tried compiling a couple of samples from the examples and was getting
>> "illegal instruction" at run-time.  I then tried Jame's Chapman's push/pull
>> examples (I did have to comment out a call to disconnect()).  Same result.
>> I'd really like to have a chance at using this because it fits a need.
>>
>> System is the latest Pi 2.  OS is Raspbian/Debian
>>
>> uname -a
>> Linux qfuel-dev 3.12.22+ #691 PREEMPT Wed Jun 18 18:29:58 BST 2014 armv6l
>> GNU/Linux
>>
>> I have the following packages installed
>>
>> libzmq-dbg:armhf  2.2.0+dfsg-2
>> libzmq1:armhf 2.2.0+dfsg-2
>> libzmq3:armhf 3.2.3+dfsg-2~bpo70+1
>> libzmq3-dev:armhf 3.2.3+dfsg-2~bpo70+1
>>
>> g++ -std=c++0x zeromq_push.cpp -o zeromq_push -lzmq
>> g++ -std=c++0x zeromq_pull.cpp -o zeromq_pul -lzmq
>>
>> Output from "strace -o output.txt zeromq_pull"
>>
>> execve("/home/kelly/C++/zeromq_pull", ["zeromq_pull"], [/* 17 vars */]) =
>> 0
>> brk(0)  = 0x1ebe000
>> uname({sys="Linux", node="qfuel-dev", ...}) = 0
>> access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or
>> directory)
>> mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
>> = 0xb6f2b000
>> access("/etc/ld.so.preload", R_OK)  = 0
>> open("/etc/ld.so.preload", O_RDONLY|O_CLOEXEC) = 3
>> fstat64(3, {st_mode=S_IFREG|0644, st_size=44, ...}) = 0
>> mmap2(NULL, 44, PROT_READ|PROT_WRITE, MAP_PRIVATE, 3, 0) = 0xb6f2a000
>> close(3)= 0
>> open("/usr/lib/arm-linux-gnueabihf/libcofi_rpi.so", O_RDONLY|O_CLOEXEC) =
>> 3
>> read(3,
>> "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\270\4\0\0004\0\0\0"..., 512)
>> = 512
>> lseek(3, 7276, SEEK_SET)= 7276
>> read(3,
>> "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1080)
>> = 1080
>> lseek(3, 7001, SEEK_SET)= 7001
>> read(3,
>> "A.\0\0\0aeabi\0\1$\0\0\0\0056\0\6\6\10\1\t\1\n\2\22\4\24\1\25"..., 47) = 47
>> fstat64(3, {st_mode=S_IFREG|0755, st_size=10170, ...}) = 0
>> mmap2(NULL, 39740, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
>> 0xb6f2
>> mprotect(0xb6f22000, 28672, PROT_NONE)  = 0
>> mmap2(0xb6f29000, 4096, PROT_READ|PROT_WRITE,
>> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1) = 0xb6f29000
>> close(3)= 0
>> munmap(0xb6f2a000, 44)  = 0
>> open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
>> fstat64(3, {st_mode=S_IFREG|0644, st_size=49745, ...}) = 0
>> mmap2(NULL, 49745, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb6ef2000
>> close(3)= 0
>> access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or
>> directory)
>> open("/usr/lib/arm-linux-gnueabihf/libzmq.so.3", O_RDONLY|O_CLOEXEC) = 3
>> read(3,
>> "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\0\206\0\0004\0\0\0"..., 512)
>> = 512
>> lseek(3, 181420, SEEK_SET)  = 181420
>> read(3,
>> "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1160)
>> = 1160
>> lseek(3, 181056, SEEK_SET)  = 181056
>> read(3, "A4\0\0\0aeabi\0\1*\0\0\0\0057-A\0\6\n\7A\10\1\t\2\n\4\22"..., 53)
>> = 53
>> fstat64(3, {st_mode=S_IFREG|0644, st_size=182580, ...}) = 0
>> mmap2(NULL, 213848, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0)
>> = 0xb6ebd000
>> mprotect(0xb6ee7000, 28672, PROT_NONE)  = 0
>> mmap2(0xb6eee000, 16384, PROT_READ|PROT_WRITE,
>> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x29) = 0xb6eee000
>> close(3)= 0
>> access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or
>> directory)
>> open("/usr/lib/arm-linux-gnueabihf/libstdc++.so.6", O_RDONLY|O_CLOEXEC) =
>> 3
>> read(3,
>> "\177ELF\1\1\1\3\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0xk\4\0004\0\0\0"..., 512) =
>> 512
>> lseek(3, 808332, SEEK_SET)  = 808332
>> read(3,
>> "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1280)
>> = 1280
>> lseek(3, 807760, SEEK_SET)  = 807760
>> read(3,
>> "A.\0\0\0aeabi\0\1$\0\0\0\0056\0\6\6\10\1\t\1\n\2\22\4\24\1\25"..., 47) = 47
>> fstat64(3, {st_mode=S_IFREG|0644, st_size=809612, ...}) = 0
>> mmap2(NULL, 900808, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0)
>> = 0xb6de1000
>> mprotect(0xb6ea2000, 61440, PROT_NONE)  = 0
>> mmap2(0xb6eb1000, 24576, PROT_READ|PROT_WRITE,
>> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xc0) = 0xb6eb1000
>> mmap2(0xb6eb7000, 24264, PROT_READ|PROT_WRITE,
>> MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb6eb7000
>> close(3)= 0
>> access("/e

Re: [zeromq-dev] Unable to build the library.

[Arnaud Kapp]

Assuming "referencia a `crypto_box_open' sin definir" means "undefined
reference to crypto_box_open" it looks like you are not linking with
libsodium.

On Fri, Jul 24, 2015 at 3:35 PM, Victor  wrote:
> Hello, i'm trying to build an app that uses zeromq as dependency (ntopng),
> however when is trying to build a part of zeromq it always fails, it is
> using 4.0.5, i have tried replacing it with the latest version 4.1.2 too and
> i still get the exact same error, i'm not sure what's wrong, here's a small
> paste, building outside that project generates the same error.
>
> A small paste  https://bpaste.net/show/490e0b203524
>
> Any idea about what's wrong?
>
> clang version 3.6.1 (tags/RELEASE_361/final)
> Target: x86_64-pc-linux-gnu
> Thread model: posix
> Selected GCC installation: /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.2
>
>
>
> Thanks
>
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>



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

Re: [zeromq-dev] Implementing a ZAP handler in C#

[Arnaud Kapp]

Hello,

The authentication should happen automatically if the socket has the
correct option configured (curve server flag, and a private key /
public key).
I am not aware of any limitation of the authentication / security code
when using PUB/SUB. It should work.

I am not familiar enough with C# to know if there is something wrong
with your code, but it looks ok.
Are you able to get this to work using the libzmq C API?

On Thu, Jul 23, 2015 at 7:16 PM, Robert Pickering
 wrote:
> I've been continuing to look at this today. To investigate further I
> build my own version of libzmq and added some debug code. What I think I
> see is the handshake in zmq::stream_engine_t::in_event is successful but
> in the sub/pub model the client sends no further data so there's nothing
> to trigger the ZAP handler. Is there anyway to force authentication to
> take place? Or is curve security just not an option with the sub/pub
> model?
>
> Thanks,
> Rob
>
> On Wed, Jul 22, 2015, at 04:54 PM, Robert Pickering wrote:
>> I'm trying to implement a ZAP handler in C#. I've updated the patho
>> sub/pub example to include curve cryptography and tried to add a ZAP
>> handler in the publisher. Here's a gist of what I have so far:
>> https://gist.github.com/robertpi/a140eaa62378c14678ad
>>
>> Basically in the publisher I bind a REP socket to
>> inproc://zeromq.zap.01. I then set the ZMQ_CURVE_SERVER and
>> ZMQ_CURVE_SECRETKEY on the publisher, while on the client I
>> ZMQ_CURVE_SERVERKEY to be the servers public key, and set it's
>> ZMQ_CURVE_PUBLICKEY and ZMQ_CURVE_SECRETKEY to be the clients
>> public/secret key.
>>
>> Before I sent up the curve options the messages follow and the example
>> works just fine. After I set the curve options the messages stop
>> following. I was expecting my ZAP handling method to be called, so I
>> could respond with with whether the client is valid or not, but it seem
>> the ZAP handler never receives a message.
>>
>> I feel I'm missing some simple step to enable the ZAP handler. Do I need
>> to send messages to inproc://zeromq.zap.01 to enable the ZAP handler? I
>> see some examples set a verbosity option and an IP filter, are these
>> messages that need to be sent to inproc://zeromq.zap.01? Or are they
>> values that need to be set somewhere else?
>>
>> Many thanks for any help!
>>
>> Rob
>>
>> --
>>   Robert Pickering
>>   robertfpicker...@fastmail.com
>> ___
>> 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



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

Re: [zeromq-dev] Zmq Security for the C# wrapper

[Arnaud Kapp]

Hello,

Welcome to the list.

What version of ZeroMQ (libzmq) are you using? If you're running on a
fairly recent libzmq the crypto API should be available -- provided
that you built libzmq with libsodium support.

I am not familiar with clrzmq4, but yes I believe it shouldn't be *too* hard.
Enabling encryption is simply setting a few options on your sockets.
However, authentication is done through the ZAP (http://rfc.zeromq.org/spec:27).
So you'd have to implement a ZAP handler (this is fairly easy) that would
validates the authentication. Unless clrzmq4 were implementing one
and providing abstraction on top of this handler.


On Mon, Jul 20, 2015 at 5:14 PM, Robert Pickering
 wrote:
> Hi all,
>
> I'm new to this list so sorry if I'm breaking some protocol that I don't
> know about :) I've done some googling about this topic, but info is a
> bit unclear to me, so I thought I write to list for clarification.
>
> Currently using zmq to provide sub/pub messaging in our C# application.
> This is all working nicely, but I'd like to add authentication and
> encryption and it seems the APIs to do this are not yet exposed to C#.
>
> From what I've read there's two implementation of zmq security, one in
> the native c++ zmq repo [1], if it's possible to use the latest version
> of zmq (as we do), then you should use this one. There also exists a
> reference implementation outside of the main repo, for people can't use
> the latest version zmq. It's available here [2].
>
> From what I've read in Pieter Hintjens's blog [3], the interface to the
> security apis doesn't look too complicated, so if I were to folk and the
> C# wrapper [4] and add the missing api calls it should be reasonable
> straight forward. Has anyone tried this before? Is there some pitfall
> that I missing that would make this a trick task?
>
> Kind regards,
> Robert
>
> [1] https://github.com/zeromq/libzmq
> [2] https://github.com/zeromq/libcurve
> [3] http://hintjens.com/blog:49
> [4] https://github.com/zeromq/clrzmq4
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev



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

Re: [zeromq-dev] Moving back cppzmq into libzmq

[Arnaud Kapp]

Hello,

Kenneth, is your patch ready?
Also, do you mean that the current cppzmq head doesn't work correctly
with current libzmq head ? (as in we shouldn't merge now).



On Thu, Jun 18, 2015 at 12:47 AM, Kenneth Adam Miller
 wrote:
> Oh, I have something to merge in to allow the newest version to work well
> together, let me do a merge request before you execute this please.
>
> On Wed, Jun 17, 2015 at 6:43 PM, Pieter Hintjens  wrote:
>>
>> Sounds good to me. It never developed as a separate project, did it.
>>
>> On Thu, Jun 18, 2015 at 12:24 AM, Arnaud Kapp  wrote:
>> > Hello,
>> >
>> > I've stumbled upon this issue https://github.com/zeromq/cppzmq/issues/48
>> > .
>> > Basically the cppzmq binding (header only, 1 file) is not versioned
>> > and not packaged on some distros.
>> >
>> > People wants this file to be tagged to ease versionning, which make
>> > sense.
>> > However, wouldn't it be even better if this was part of libzmq. I
>> > *believe* this was the case a long time ago, but the choice was made
>> > to split them.
>> >
>> > I don't know the reason, but maybe it's worth considering merging them
>> > back. After all, zmq.hpp is a very thin wrapper and I don't think it'd
>> > be too annoying to maintain as part of libzmq.
>> >
>> > What are your thoughts on this?
>> >
>> > --
>> > Kapp Arnaud - Xaqq
>> > ___
>> > 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
>
>
>
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>



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

Re: [zeromq-dev] Questions about C4.1

[Arnaud Kapp]

Hello,

> Is creating a stable release fork a requirement? If so, at what points in a 
> project's lifecycle should such a fork be created?

No, we do this for libzmq but for example czmq or zmqpp use tags to
manage releases.



On Sat, Jun 27, 2015 at 1:23 AM, Paulmichael Blasucci
 wrote:
> Apologies if this is the wrong place to ask the following but...
>
> I recently started migrating fszmq (the F# binding for ZeroMQ) over to the
> C4.1 process. However, I've got some questions:
>
> 1. Is creating a stable release fork a requirement? If so, at what points in
> a project's lifecycle should such a fork be created?
>
> 2. Does the exclusion of topic branches also include older versions of the
> project (which currently only exist as branches)?
>
> Cheers!
>
> Paul
>
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>



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

Re: [zeromq-dev] Heartbeating on libzmq master

[Arnaud Kapp]

Hello,

This is a cool patch indeed :)

Quick feedback: I feel like the ZMQ_HEARTBEAT_TTL being in deciseconds
while the others are in milliseconds will bite me someday.

On Wed, Jun 24, 2015 at 9:00 PM, Pieter Hintjens  wrote:
> Hi all,
>
> I just want to let you know that Jonathan Reams has sent a patch that
> adds PING/PONG heartbeating to libzmq master. This is following the
> ZMTP/3.1 draft spec at http://rfc.zeromq.org/spec:37.
>
> -Pieter
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev



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

[zeromq-dev] Moving back cppzmq into libzmq

[Arnaud Kapp]

Hello,

I've stumbled upon this issue https://github.com/zeromq/cppzmq/issues/48 .
Basically the cppzmq binding (header only, 1 file) is not versioned
and not packaged on some distros.

People wants this file to be tagged to ease versionning, which make sense.
However, wouldn't it be even better if this was part of libzmq. I
*believe* this was the case a long time ago, but the choice was made
to split them.

I don't know the reason, but maybe it's worth considering merging them
back. After all, zmq.hpp is a very thin wrapper and I don't think it'd
be too annoying to maintain as part of libzmq.

What are your thoughts on this?

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

Re: [zeromq-dev] zmq context's thread priority

[Arnaud Kapp]

Hello,

Note that this is my understanding of how it works, but I am not a
core dev so I am not sure. I may be totally wrong.

If the IO thread does not run because of not enough CPU time I guess a
lot of thing can go wrong. As far as I know, messages go through the
IO thread for dispatching.
The I/O thread not running could then could prevent you from both
sending and receiving message.

As for your second question, I do not know. If your application as
long running one, you could try to manually change the priority of the
threads and see if it fixes your problem.


On Mon, Jun 8, 2015 at 12:30 PM, Leonard Michelet
 wrote:
> Hello, I use ZeroMQ on a Preempt_rt kernel and I have some connection problem 
> on a virtual machine.
> I run automated tests on this virtual machine and its CPU is quite busy, and 
> I noticed that my real time application, which use zmq, has 2 threads not 
> with real time scheduler, but time shared.
> These thread are usually in "epoll_wait" kernel's function, and I suppose 
> it's internal thread created by ZeroMQ (I set ZMQ_IO_THREADS to 1).
> I would like to know what is the purpose of these thread, to understand what 
> symptoms I could have if these thread were never run because of not enough 
> CPU time.
> Would it prevent me from receiving message? Would it prevent me to send 
> message? Both?
>
> And my next question would be : is there a way to set priority on these 
> thread?
>
> Thanks for reading.
> Léonard.
>
> P.S : the application set real time priority using pthread_setschedparam 
> which is a per thread setting, so it doesn't change the defaullt priority of 
> new thread, and we would like to avoid setting such a default.
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev



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

Re: [zeromq-dev] Coveralls

[Arnaud Kapp]

Hello,

I don't know coveralls, but I assume it is a elaborate code coverage tools.
Basically it tells you how well the codebase is covered by the unit
test suite. I suppose as long as the tool is free for open source it
cannot hurt to merge the pull request.

At best it's useful to see how well the tests cover the codebase, and
worst you don't use it.



On Fri, May 22, 2015 at 6:39 PM, Arnaud Loonstra  wrote:
> Has anybody got experience with coveralls? I received this PR:
> https://github.com/zeromq/pyre/pull/66
> but I have no experience with this service or approach.
>
> Rg,
>
> Arnaud
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev



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

[zeromq-dev] Websocket status

[Arnaud Kapp]

Hello,

I'd like some clarification about the current state of Websocket
support in the ZeroMQ community.
This mail comes from this issue
(https://github.com/zeromq/zmqpp/issues/108) raised on the zmqpp
tracker.

There is this RFC http://rfc.zeromq.org/spec:39 I know about. Also
this project https://github.com/zeromq/zwssock and that one
https://github.com/zeromq/JSMQ.

Is my understanding correct:
 + Websocket support must be fully implemented in bindings (ie,
not just a small wrapper around
libzmq code)
 + This support is therefore not trivial to implement.

Assuming I understand correctly, wouldn't it make sense to, in the
long run, implement Websocket as a libzmq transport, so that any
binding can use them easily? Has there been any attempt as of yet?

Am I missing something wrt websocket ?

Thanks,

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

Re: [zeromq-dev] Naming of the Pyre project

[Arnaud Kapp]

What about simply pzyre?

On Sun, Apr 19, 2015 at 12:58 PM, Pieter Hintjens  wrote:
> If the 'xyre' naming scheme isn't acceptable, then I'd suggest a
> totally different name, outside the zmq/zyre schemes.
>
> On Sun, Apr 19, 2015 at 11:38 AM, Arnaud Loonstra  wrote:
>> Hi,
>>
>> I don't know if people have followed the discussion on the Pyre github.
>> It seems there is another project called Pyre. Therefore there's a
>> discussion for renaming Pyre in order to have it listed on Pypi.
>>
>> https://github.com/zeromq/pyre/issues/14
>>
>> I'm personally not so much troubled by not being listed on Pypi but as
>> more people get involved this is of more importance.
>> Suggested names are now: just zyre, pyzyre however these also conflict
>> with existing zmq projects.
>>
>> Another note about this. As zyre python bindings are generated nowadays
>> I would like the python zyre module to detect whether it can access the
>> C library or revert to the native python zyre (Pyre). This is being done
>> for a lot of python modules. (i.e.
>> http://api.mongodb.org/python/current/api/pymongo/index.html#pymongo.has_c)
>>
>> Does anybody have any suggestions, objections, advice etc?
>>
>> Rg,
>>
>> Arnaud
>> ___
>> 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



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

Re: [zeromq-dev] Canonical language for the Guide

[Arnaud Kapp]

Hello,

I also believe that using C/CZMQ is a good choice. CZMQ offers an easy
to use C API which I believe mostly everyone would understand.

I don't know much about code generation. I believe that example in
other languages should be written using a specific binding: this often
more than just
a wrapper around the low-level C API. I have no idea how well this can work.

Basically I am against using any other language other than the
low-level C API or CZMQ. My reasoning is that if you understand the C
API code, you should understand
any binding API. I don't think the opposite is true, especially wrt
messages vs parts, context management and socket linger. This is
because bindings hide this stuff,
but I don't think hiding stuff is good in a reference guide.

Anyway, the current guide is very well written and extremely useful
and I trust the next one will be too !

On Tue, Apr 7, 2015 at 9:13 PM, Brian Knox  wrote:
> I think that C/CZMQ is a reasonable choice.
>
> I'm intrigued by the idea of being able to generate examples in different
> languages from a DSL - but concerned it might add confusion instead of
> clarity.
>
> Brian
>
>
>
> On Tue, Apr 7, 2015 at 2:35 PM, Gregg Irwin  wrote:
>>
>> Hi Pieter,
>>
>> PH> What's the best canonical language?
>>
>> PH> My personal preference is C/CZMQ, which is high level and clean.
>>
>> PH> My second choice would be a high level modeling language.
>>
>> +1
>>
>> While my only daily C is the vitamin, I think C is the best choice. As
>> you say, you will never please everyone. Of course, I'm also a huge
>> fan of DSLs and code generators. The issue I see in this context is
>> that the bindings, and 0MQ itself, are moving targets. The upside is
>> that the old generators are still valid even as you create new
>> templates when change comes.
>>
>> If you can keep the DSL/MOP simple enough, it could be a win even if
>> only used for the C examples. The more general it needs to be, the
>> more gratification may be delayed. Do you have thoughts or examples on
>> the language or output side already gestating?
>>
>> -- Gregg
>>
>> ___
>> 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
>



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

Re: [zeromq-dev] Re : Re: Which c++ binding choose

[Arnaud Kapp]

Hello,

They are all maintained. The cppzmq (low-level binding) is very
straightforward so that's why there isn't much activity going on. It
works, and it gets updated when libzmq changes stuff.
Thomas introduced azmq, so let me talk about zmqpp.

If integrating with boost::asio is not useful to you, I'd recommend
you give zmqpp a try.
It is still maintained, but as it is fairly complete there isn't much
activity going on. We implement features on a "someone-needs" basis.
It requires a c++11 compiler.
The API is, in my opinion, quite easy to use.


On Fri, Mar 13, 2015 at 2:58 PM, Thomas Rodgers  wrote:
>> I looked to azmq CMakelists and I seems mandatory to have/use boost no?
>
>
> Boost is mandatory, yes. It would be possible (and not particularly
> difficult) to make a version that works with the standalone Asio library,
> but as all of my projects assume the use of Boost, it hasn't been a priority
> for me.
>
> On Friday, March 13, 2015, Leonard Michelet 
> wrote:
>>
>> I'm using c++11, but not boost :(
>> I started using cppzmq but I miss some functions :
>> Stopping socket monitor properly.
>> Detected client deconnection from server side (without using a PUB
>> socket).
>>
>> I looked to azmq CMakelists and I seems mandatory to have/use boost no?
>> Thanks for answering.
>>
>> - Thomas Rodgers  a écrit :
>>
>> > I am the author of azmq it is an active project (most recent commit
>> > within
>> > the last week).
>> >
>> > It is heavily tied to the way that Boost Asio does things. If you
>> > already
>> > have/plan on having a dependency on the Boost libraries and are
>> > comfortable
>> > with Asio then perhaps it will be a fit for you.
>> >
>> > On Friday, March 13, 2015, Leonard Michelet
>> > 
>> > wrote:
>> >
>> > > Hello everyone, I must use zeromq for a work project written in c++
>> > > and I
>> > > wonder which c++ binding I should use.
>> > > On the c++ binding page (http://zeromq.org/bindings:cpp), there are 3
>> > > of
>> > > them, but I'm not sure if each of them are still active.
>> > > Thank you,
>> > > Léonard.
>> > > ___
>> > > 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
>
>
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>



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

Re: [zeromq-dev] zcertstore_insert: Assertion 'rc == 0' failed.

[Arnaud Kapp]

This is just a guess, but since you're saying that it works on an
other machine, it may be correct.

Did you compile libzmq with libsodium support?

On Mon, Mar 9, 2015 at 2:20 PM, Bachmair Florian - flexSolution GmbH
 wrote:
> I get this error "zcertstore_insert: Assertion 'rc == 0' failed."
>
>
>
> When I execute this code:
>
>
>
> #include "czmq.h"
>
> static int s_send(void *socket, char *string);
>
> static int s_sendmore(void *socket, char *string);
>
> int main(void) {
>
> puts("Publisher");
>
> zctx_t *context = zctx_new();
>
> zauth_t *auth = zauth_new(context);
>
> zauth_allow(auth, "127.0.0.1");
>
> assert(auth);
>
> puts("1");
>
> zauth_set_verbose(auth, true);
>
> zauth_configure_curve(auth, "*", ".curve");
>
> puts("2");
>
>
>
> zcert_t *server_cert = zcert_load(".curve/mycert.pvt");
>
> assert(server_cert);
>
> void *publisher = zsocket_new(context, ZMQ_PUB);
>
> zcert_apply(server_cert, publisher);
>
> zsocket_set_curve_server(publisher, 1);
>
>
>
> while (1) {
>
>s_sendmore(publisher, "A");
>
>s_send(publisher, "We don't want to see
> this");
>
>s_sendmore(publisher, "B");
>
>s_send(publisher, "We would like to see
> this");
>
>sleep(1);
>
> }
>
> zmq_close(publisher);
>
> zmq_ctx_destroy(context);
>
> puts("exit");
>
> return 0;
>
> }
>
> // Convert C string to 0MQ string and send to socket
>
> static int s_send(void *socket, char *string) {
>
> int size = zmq_send(socket, string, strlen(string), 0);
>
> return size;
>
> }
>
> // Sends string as 0MQ string, as multipart non-terminal
>
> static int s_sendmore(void *socket, char *string) {
>
> int size = zmq_send(socket, string, strlen(string),
> ZMQ_SNDMORE);
>
> return size;
>
> }
>
>
>
> I have compiled everything exactly like it is described in
> http://hintjens.com/blog:49#toc0
>
>
>
> The odd thing is that I had this code running on a other machine sucesfully.
>
>
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>



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

Re: [zeromq-dev] adding other file descriptors to zmq::pollitem_t array

[Arnaud Kapp]

Hello,

Yes you can poll on native file descriptor without problem.

From the documentation (http://api.zeromq.org/4-1:zmq-poll): ZMQ_POLLIN
"For ØMQ sockets, at least one message may be received from the socket
without blocking. For standard sockets this is equivalent to the
POLLIN flag of the poll() system call and generally means that at
least one byte of data may be read from fd without blocking."

On Tue, Mar 3, 2015 at 11:15 PM, André Caron  wrote:
> AFAICT, zmq_poll supports any native fd by design.  What fds are accepted is
> system dependant.  For example, on Windows, it only accepts sockets (but not
> regular files like stdin).  On other platforms, YMMV I guess.
>
> Cheers,
>
> André
>
> On Tue, Mar 3, 2015 at 4:51 PM, alex.  wrote:
>>
>> I am building a threaded file monitoring tool using zmq and inotify. I
>> discovered that I will have a nasty block when I want to end a thread
>> that is currently blocking while watching a file.
>>
>> Since I am solving similar problems of threads waiting for zmq
>> messages with a double polling on two separate endpoints, one being
>> the actual endpoint and the other being a custom SIGTERM-message
>> broadcast from the main thread, I was wondering if I could do the same
>> here. As I want to solve all thread synchronisation problems using
>> such polling and zmq messages (stearing clear of stuff like mutexes
>> and signals), this seems to be a good go.
>>
>> I dived into the code and realized that the zmq_poll() is basically a
>> wrapper for the system's poll() function, which is also the suggested
>> polling method for inotify. I went ahead and simply added inotify's
>> file descriptor (fd) as an item to my zmq::pollitem_t array (passing a
>> 0 as the socket):
>>
>> { 0, fd, ZMQ_POLLIN, 0 }
>>
>> This seems to work quite well actually! Now I wanted to ask if this is
>> okay for production use. I even let the ZMQ_POLLIN in, as I am not
>> sure if zeromq's polling will handle the system's POLLIN well enough,
>> but the inverse may just as well be true?
>>
>> So is it advisable to just shove the fd of inotify into zmq's polling
>> function?
>>
>> Thanks!
>> alex.
>> ___
>> 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
>



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

Re: [zeromq-dev] meaning of ZMQ_EVENT_CONNECTED

[Arnaud Kapp]

Hello,

I believe it's not enough. Well, your tests seem to prove it's not enough.
My guess would be that the socket is indeed connected, but the
subscriptions have not yet been sent (or acknowledged by the
publisher). I may be wrong here, I don't know much
about the ZMTP protocol.

What you could do this (please wait for more experienced ZMQer's to
confirm or not):
Add a router socket on the publisher's side. Connect to this
second with a dealer from the subscriber's side.
Send some kind of PING message from the publisher (like every
second, or w/e suits you).
Connect your subscriber.
When your subscriber receive a PING message, then send an "I AM
READY" message to the router socket, using your dealer socket.
When receiving the "I AM READY" message on the router socket, your
publisher can start sending real message to the subscriber.

This looks a bit daunting. Depending on what you're doing, it might be
preferable to simply add a sleep() before sending the first message on
the publisher.


On Tue, Feb 3, 2015 at 8:35 PM, McMillan, Scott A
 wrote:
> Hi,
>
> I'm dealing with the pub-sub "slow joiner" problem.  As I understand it,
> the problem arises, in part, because connections are asynchronous and
> zmq_connect() returns before the connection is actually established.
>
> I hooked up a monitor and wait until the monitor indicates the socket is
> in the CONNECTED state before publishing.  However, even with the socket
> in the CONNECTED state, the first few messages are usually lost.
>
> Does ZMQ_EVENT_CONNECTED actually mean that the connection is fully
> established and ready for pubs?  Or something lesser?
>
> Thanks,
> Scott
>
> P.S. Sorry if I'm just re-asking this question:
> http://grokbase.com/t/zeromq/zeromq-dev/151enr4dae/zmq-event-connected-and-
> router-socket.  Not sure if pub-sub is sufficiently different than
> router-router change the meaning of ZMQ_EVENT_CONNECTED.
>
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev



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

Re: [zeromq-dev] Notes from a hackathon

[Arnaud Kapp]

@Doron: Yes I like multi part because its a very simple way build
"multiple-fields message". I once considered using protobuff + raw
socket for a pet project of mine, and I ended using ZMQ framing
because it was simpler.
The problem if we pick an other serialization solution is that it
needs to built-in libzmq. Per-binding serialization would be a
disaster IMO.


> Arnaud - you can do that today, just use synchronization object, however this 
> is not really work, what if you call receive and there is no message 
> currently? so you block and the socket is still locked, maybe for long time. 
> Now you want to send from another thread but socket is locked.

Ah yes that's true, you'd have to use non-blocking read and such. I
reckon this is clearly not as practical as a fully thread safe socket
would be.


> Multi-part does easy serialization, yes. Not in C though. We've
> learned how to do variable list serialization with zproto-compatible
> picture sending in CZMQ. Is this a sufficient alternative? I think so.
> zsock_send() was essential to making actors cheap enough to use
> widely. egrep zsock_send *.c in malamute-core/src.

I'd argue that using zmsg_addstr() / zmsg_add() / zmsg_pop() are fine
for serialization. Agreed, when using the raw libzmq API this is not
as nice.


> If you're doing multipart a lot in an application, you can replace
> that with zproto. You already have contracts then, why not make them
> explicit and documented? That's always a win in my experience.

Yes I'm using multi-part quite a lot. I manually documented those
contracts and they are enforced by assert() (for anything that does'nt
come from the external world, obviously).
I'd argue that using c++ stream operator is easier, but I'd really
have to convert part of my code to zproto and give it an honest try.


> Picture sending solves a cross-language problem, namely how to
> construct zproto-style commands without using dedicated codecs. While
> the API is C-ish, the functionality is not. I'd expect that to be
> wrapped in bindings.

Yes but I believe pictures are sometime not practical. (I think) they
require that the picture be known when the message is being created.
I have some code where I do the following (if it's that weird / bad
please tell me):
   Some code create a message, push the identity frame and then some
application-level header.
   Control flow is handed to some other function, along with a
reference to the message. This function push a "command" frame and
more data (type and how many are unkown to the previous piece of
code).
   Control flow return to initial code, and send the message.

On the other side of the socket, I do something similar:
   Pop application-level header. Pop the "command" frame.
   Based on those 2 piece of data, call a function (again, along with
a reference to the message).
   Function will expect some kind of data layout, will extract it and
perform work.

In this scenario, the first part of the code doesn't know (or care,
really) about the "real" content of the message. In case my
explanation sucked, this is a bit similar to the ZAP rfc: the request
contains some "must be there" frames, and then some "zero or more
opaque frames". In case of ZAP, those opaque frames only make sense to
mechanism specific code. In my example, they only make sense to some
specific message handling code. I do not really see how ZAP could be
that simple and nice to work w/ if it wasn't for multi-part messages.


> The main goal with this is simplicity and accuracy. I'm tired of
> teaching people ZeroMQ constructs that are clearly over-designed and
> disconnected from reality in subtle ways. Each apology for friction
> ("sorry, but don't use REQ-REP, they are kind of weird", "sorry,
> IDENTITY is not really identity", "sorry, message sometimes means
> frame and sometimes message") really signals costs up and down the
> stacks.

This is a valid point. However, a good read through the guide really
help understanding how things work. I wouldn't be that surprised if
a lot of people having trouble understanding frames vs message or
REQ-REP problem didn't really read the zguide.
So *maybe* a documentation effort is what is needed to better explain
those thing. I agree about the IDENTITY tho.
I do not know, I don't have much experience teaching, and none teaching ZMQ.

Anyway, no matter what it's going to be interesting.

On Tue, Feb 3, 2015 at 11:04 PM, Pieter Hintjens  wrote:
> Thanks for the questions. I'd try to flatter by saying how great these
> questions are, except I know you're all way too smart to fall for
> that. :)
>
> Let me answer a bunch of questions in one go:
>
> * Sorry for not posting this here. I've written a more detailed
> analysis of the motivation for this thread (and experiments):
> http://hintjens.com/blog:84.
>
> * The main goal with this is simplicity and accuracy. I'm tired of
> teaching people ZeroMQ constructs that are clearly over-designed and
> disconnected from reality in subtle wa

Re: [zeromq-dev] Notes from a hackathon

[Arnaud Kapp]

Hello everyone,

I have read this thread and the blog post from Pieter.
I am looking forward to some of those things, but I have some reserve
about other points. I'll try to explain what I think, and why.

I agree that ZMQ_IDENTITY is a bit confusing. Allowing remote client
to set routing information is a bit counterintuitive. Also there is
risk for impersonation. If a peer disconnect, an other one could
"steal" it's identity. I believe that relying on the socket identity
to identify peer is not a robust enough approach, even when using
CURVE.
Storing the peer routing id in the message's properties seems like a good idea.

I think thread-safe socket would be cool. As in great to have in some
particular situation, but most of the case it shouldn't be needed.


Aiming for a cleaner and simpler ZMQ internal code is good. We must be
careful however that this will not make the end-user's life harder. I
believe I see 2 points that would make my life harder as a ZMQ user
today if we had what we is discussed here:
+ The removal (or depreciation) of the REQ-REP socket. While
fragile over the network, I find them very useful for sending
synchronous messages between threads.
+ Removal / depreciation of multipart messages. Read below.

The next paragraph is about multipart messages. Let me be honest and
state that I have no idea of the real performance penalty induced by
multipart messages. What I want to defend here is their usefulness.
I *really* like multipart messages. To be honest, this is one of the
many features that made me try ZMQ. This is also the feature that
helps me most: I my current project, I mainly pass messages around
between thread, so I have less use for other awesome features like
auto reconnect or security.

IMO framing is very good because it allows you to send (and receive)
various kind of data *easily*. I like doing this kind of stuff:

zmqpp::message msg;
msg << "HELLO WORLD" << 42 << 13;
s.send(msg);

And on the receiving end:
   std::string cmd;
   int value_1, value_2;
   msg >> cmd >> value_1 >> value_2;

Sure, there is no verification of the message content, the application
would even crash if a message was badly formatted. However, this is
not a concern when messages are flowing on inproc:// : I know that I
send and I know what to receive. I believe that the picture, which is
great in CZMQ, is not really appropriate for C++ and maybe other
language. My point is (for c++) that stream operator are a more
apprioriate / natural way of doing what the picture does.

ZProto is mentioned as a possible replacement to framing. Disclaimer:
I've taken a look at zproto, but I have never used it.
I think it's a great project with some strong advantages and real
world use case. However, it comes at the cost of more complexity. This
is what I meant when talking about making the end-user's life harder.
Do I want to use zproto to design complex, client-server protocol?
Yes, I probably should give it a try.
Do I really want to use zproto when sending 3-4 frames on an inproc
socket? I'd rather avoid it and keep it as simple as possible.

> In my opinion, maintaining some kind of multi-frame abstraction at the API 
> level is in fact very useful to applications, even if they are sent 
> atomically on the implementation level as you describe.
I totally agree with Joe on this point.


One last thing about multithreaded socket. Maybe this is completely
stupid as I know little about libzmq's internal, but wouldn't it be
possible to make explicit thread safe socket by providing a
zmq_socket_lock()/unlock() function that would allow ZMQ internal to
serialize multiple frames properly ?
Sure, this is a not as classy as properly thread-safe socket, but
would work in most case: grab the socket from shared memory, lock it,
write/receive, unlock it.



On Tue, Feb 3, 2015 at 3:52 PM, Luna Duclos
 wrote:
> I'm not sure if I like having picture as a libzmq level thing.
> It really only makes sense for C language bindings in my book. most other
> bindings use their own serialization mechanisms.
>
> On Tue, Feb 3, 2015 at 2:06 PM, Pieter Hintjens  wrote:
>>
>> On Tue, Feb 3, 2015 at 1:01 PM, Doron Somech  wrote:
>>
>> > Pieter - regarding the blog post, I'm not sure about setting the routing
>> > id
>> > on the socket
>>
>> Indeed, that isn't atomic with sending and so can't work with
>> threadsafe sockets. I've changed the article.
>>
>> I think we can either get the routing id as a message property, and/or
>> add a "reply to message" semantic that does this implicitly. The
>> second is easier for simple servers, the first is better for realistic
>> servers.
>>
>> Since it only applies to server sockets, I think we would benefit from
>> a zserver_reply () method (or similar).
>>
>> We might also think of moving the picture send/recv API into libzmq at
>> some point since it's the immediate replacement for framing.
>>
>> > I also have a question regarding the session management (really liked
>> > it),
>

Re: [zeromq-dev] ZMQ vs SPI: FD shenanigans

[Arnaud Kapp]

Haha be careful Thomas or you will wake Pieter :)

Well I am mixing socket operations binds/connects with opening and
closing files (and reading and writing from/to files).
I also use ZMQ to poll on my files' descriptors. So at first sight it
doesn't look like a ZMQ bug.

I see two things to try:
  * Try with a more stable version of libzmq -
https://github.com/zeromq/zeromq4-1
  * Upgrading to a more recent kernel and to gcc 4.9 if those are available.

Good luck !

On Tue, Jan 20, 2015 at 6:45 PM, Thomas Rodgers  wrote:
>> At least in the C++ version, the problem is relatively fragile
>
>
>>  I always see the problem in my pure-C test
>
>
> There are those that maintain that C is a simpler and more robust language
> than C++ :-)~
>
> On Tue, Jan 20, 2015 at 11:32 AM, Olaf Mandel 
> wrote:
>>
>> Hello,
>>
>> Am 20.01.2015 18:07, schrieb Arnaud Kapp:
>> > I don't really see anything in the small example that could cause a bug.
>> > I am myself using libzmq (with zmqpp as a wrapper) on a Raspberry Pi +
>> > a Piface digital card (which is a SPI device), and I have no trouble.
>> >
>> At least in the C++ version, the problem is relatively fragile: it only
>> occurs if mixing ZMQ socket operations binds/connects with opening and
>> closing files. There are cases where I also don't see the problem.
>> Weirdly, I always see the problem in my pure-C test...
>>
>> > My kernel version is 3.12.28+ and I use a recent (a few commits behind
>> > HEAD) version of libzmq.
>> -Snipp-
>>
>> Good point, my machine and version numbers are:
>>
>> CPU:   Freescale i.MX537 (Cortex-A8, NEON)
>> GCC:   4.8.1, cross-compiling
>> Linux: 3.10.28 + many platform patches
>> ZMQ:   zeromq/libzmq.git @ be23e699c
>>
>> Any other info of interest?
>>
>> Best regards,
>> Olaf Mandel
>> --
>> Olaf Mandel
>> phone: +49-89-189166-250
>> fax:   +49-89-189166-111
>> Menlo Systems GmbH
>> Am Klopferspitz 19a, D-82152 Martinsried
>> Amtsgericht München HRB 138145
>> Geschäftsführung: Dr Michael Mei, Dr Ronald Holzwarth
>> USt-IdNr. DE217772017, St.-Nr. 14316170324
>>
>>
>> ___
>> 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
>



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

Re: [zeromq-dev] ZMQ vs SPI: FD shenanigans

[Arnaud Kapp]

Hello,

I don't really see anything in the small example that could cause a bug.
I am myself using libzmq (with zmqpp as a wrapper) on a Raspberry Pi +
a Piface digital card (which is a SPI device), and I have no trouble.

My kernel version is 3.12.28+ and I use a recent (a few commits behind
HEAD) version of libzmq.

On Tue, Jan 20, 2015 at 4:28 PM, Thomas Rodgers  wrote:
> No, not really. libc++ doesn't do anything particularly interesting with
> fd's but I just wanted to formally rule it out.
> Unfortunately I don't have a system (or any experience dealing) with SPI
> devices. I don't think libzmq does anything particularly 'funky' with any of
> the file descriptors it manages though (at least based on my reading of the
> source).
>
> On Tue, Jan 20, 2015 at 8:56 AM, Olaf Mandel 
> wrote:
>>
>> Hello Thomas,
>>
>> thank you for the quick answer.
>>
>> Am 20.01.2015 15:11, schrieb Thomas Rodgers:
>> > Do you see the same behavior if you replace C with fopen() ?
>> -Snipp-
>>
>> Not quite: if the error occurs, the behaviour is the same as before. But
>> now the error _always_ happens: closing the file descriptor in the C
>> version of the test makes no difference. New test below:
>>
>>
>> /*
>>  *  Compile with:
>>  *  g++ -Wall -Werror -Wextra -pedantic -x c -o test test.c -lzmq
>>  */
>> #include 
>> #include 
>> #include 
>> #include 
>> #include 
>> #include 
>>
>>
>> /*#define ADDR "tcp://127.0.0.1:8000"*/
>> #define ADDR "inproc://addr"
>>
>>
>> /*
>>  *  The program always shows the problem (independent of the presence
>>  *  of D) for the following permutations of the blocks:
>>  *  - A B C D
>>  *  - A C B D
>>  *  - A C D B
>>  *  - C A B D
>>  *  - C A D B
>>  *  - C D A B
>>  *
>>  *  With the constraint that A must be before B and C before D, there
>>  *  are no further valid permutations.
>>  *
>>  *  For the TCP address, the error message is: No such device
>>  *  For the inproc address, it is: Resource temporarily unavailable
>>  */
>> int main()
>> {
>> void*  ctx;
>> void*  skt;
>> FILE*  f;
>> intfd;
>> struct spi_ioc_transfer pcks;
>>
>> ctx = zmq_ctx_new();/* A */
>>
>> skt = zmq_socket(ctx, ZMQ_PUB); /* B */
>> zmq_bind(skt, ADDR);
>>
>> f = fopen("log", "w");  /* C */
>> (void)sizeof(f);
>>
>> fclose(f);  /* D */
>>
>> /* The following always last */
>> fd = open("/dev/spidev32766.0", O_RDWR);
>> memset(&pcks, 0, sizeof(struct spi_ioc_transfer));
>> ioctl(fd, SPI_IOC_MESSAGE(1), &pcks);
>> printf("errno: %s\n", strerror(errno));
>>
>> return 0;
>> }
>>
>>
>> The one advantage of this is: I now at least can see the FILE structure
>> and the contained _fileno member.
>>
>> Any further thoughts?
>> Olaf Mandel
>> --
>> Olaf Mandel
>> phone: +49-89-189166-250
>> fax:   +49-89-189166-111
>> Menlo Systems GmbH
>> Am Klopferspitz 19a, D-82152 Martinsried
>> Amtsgericht München HRB 138145
>> Geschäftsführung: Dr Michael Mei, Dr Ronald Holzwarth
>> USt-IdNr. DE217772017, St.-Nr. 14316170324
>>
>>
>> ___
>> 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
>



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

Re: [zeromq-dev] Propose removal of ZMQ_IDENTITY_FD socket option from libzmq 4.1rc and trunk

[Arnaud Kapp]

> I'm also fine just marking deprecated and reverting my size check change.

No don't do this! Preventing memory corruption can only be a good thing.

> It wasn't part of any release (except pre-release).

Oh I didn't realize it was that new.
Well in that case, if we're going to remove it we might as well do it
now indeed.

On Fri, Jan 9, 2015 at 7:07 PM, Peter Kleiweg  wrote:
> Arnaud Kapp schreef op de 9e dag van de louwmaand van het jaar 2015:
>
>> Hello,
>>
>> I agree that this option is weird, and it's behavior not properly
>> defined (the fd_t stuff).
>> However, shouldn't we mark this option as deprecated instead, and
>> remove it in a later version?
>
> It wasn't part of any release (except pre-release).
>
>
>
>
> --
> Peter Kleiweg
> http://pkleiweg.home.xs4all.nl/
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev



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

Re: [zeromq-dev] Propose removal of ZMQ_IDENTITY_FD socket option from libzmq 4.1rc and trunk

[Arnaud Kapp]

Hello,

I agree that this option is weird, and it's behavior not properly
defined (the fd_t stuff).
However, shouldn't we mark this option as deprecated instead, and
remove it in a later version?

On Fri, Jan 9, 2015 at 6:43 PM, Pieter Hintjens  wrote:
> Great :-)
>
> On Fri, Jan 9, 2015 at 6:38 PM, Thomas Rodgers  wrote:
>> Excellent, I submitted issue 1296 to capture it. I will put together the
>> pull req over the weekend.
>>
>> On Fri, Jan 9, 2015 at 11:26 AM, Pieter Hintjens  wrote:
>>>
>>> Sounds good.
>>>
>>> On Fri, Jan 9, 2015 at 6:00 PM, Thomas Rodgers 
>>> wrote:
>>> > I would like to propose removing this option before it becomes part of
>>> > an
>>> > officially released API, but I would like to reassurance that this is an
>>> > appropriate course of action before doing so.
>>> >
>>> > My reasoning for removing it is as follows -
>>> >
>>> > * It is the only option to zmq_getsockopt() that treats option_value as
>>> > a
>>> > value/result parameter, all others treat option_value as strictly a
>>> > result
>>> > parameter.
>>> >
>>> > * A brief survey of the Posix getsockopt() API shows a similar lack of
>>> > using
>>> > option_value as a value/result parameter.
>>> >
>>> > * The original implementation requires the caller to ensure that the
>>> > returned buffer is sufficient to hold an fd_t, but fd_t is not part of
>>> > ZeroMQ's public API. It is conditionally defined by platform and on
>>> > Windows
>>> > has two potential definitions.
>>> >
>>> > * I'm not comfortable with this blind faith assignment through a
>>> > pointer, so
>>> > I submitted a length check change. Unfortunately this introduces a whole
>>> > new
>>> > class of potential usage problems for this option.
>>> >
>>> > * I don't know what the intended use case for the option is, but I infer
>>> > from the test_id2fd test case, that is to build a map of router identity
>>> > to
>>> > fd, perhaps to pass fd to getpeername(2) and build a map of identity to
>>> > peername. If this is indeed the case, this use case is already handled
>>> > by
>>> > calling zmq_msg_get(&part, ZMQ_SRCFD), on the message part containing
>>> > the
>>> > identity frame.
>>> >
>>> > What am I missing here?
>>> >
>>> >
>>> > ___
>>> > 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
>>
>>
>>
>> ___
>> 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



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

Re: [zeromq-dev] Should I use socket option ZMQ_TCP_ACCEPT_FILTER in ZeroMQ 4.0?

[Arnaud Kapp]

I'd say write that it is deprecated.
One should use the ZAP API as it's more flexible and allows for more
configuration.

As soon as the ZAP API is available, encourage your user to use it
over other means of filtering / securing connection.

At least that's my opinion.

On Thu, Jan 8, 2015 at 3:35 PM, Peter Kleiweg  wrote:
>
> The API doc version 4.1 for setsockopt option
> ZMQ_TCP_ACCEPT_FILTER says this option is deprecated, and you
> should use the ZAP API instead.
>
> The API doc version 4.0 doesn't say this, but the ZAP API is
> already available.
>
> Writing bindings for ZeroMQ 4, should I write in the docs that
> this option is deprecated since 4.1, or should I just write that
> it is deprecated?
>
>
> --
> Peter Kleiweg
> http://pkleiweg.home.xs4all.nl/
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev



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

Re: [zeromq-dev] zmq_poll performance question

[Arnaud Kapp]

Hey,

I did not check for performance improvement, I simply tested that my
program continued to work.
The thing is, my poller only has 1 zmq socket and 1 file descriptor
(that relies on POLLPRI -- its a GPIO pin). So in my case I could'nt
really check
for perf improvement. Also I am running this on a Raspberry Pi.

I used it for about 1hour before sending the previous mail. Gonna work
with this patch applied next week, making sure it keeps working.

On Thu, Dec 11, 2014 at 2:39 PM, Francis Le Bourse
 wrote:
> Hello,
> On 12/10/2014 6:54 PM, Arnaud Kapp wrote:
>>
>> Hello,
>>
>> Sorry it took me a while, but I finally go to test your patch.
>> My setup that use POLLPRI seems to work properly with your patch applied
>> :).
>
> Good. Do you see a performance improvement ? How long have you been using it
> ?
>>
>>
>> Did you submit a PR to get it merged into libzmq master yet?
>
> No, not yet. I was waiting for feedback before. And I had another issue with
> a memory hog in libzmq.
> Cheers,
> Francis
>
>
>>
>> On Fri, Nov 28, 2014 at 11:35 AM, Francis Le Bourse
>>  wrote:
>>>
>>> On 11/24/2014 8:08 PM, Arnaud Kapp wrote:
>>>>>
>>>>> Currently, the patch is written for 3.2.4. I'll wait to put it in
>>>>> libzmq
>>>>> master
>>>
>>> The first patch for 3.2.4 had an issue in zmq_poll(), I had tried a
>>> little
>>> too aggressive optimization by bypassing the "first_pass" processing. It
>>> is
>>> fixed in the current one.
>>> The patch for the current head is clean.
>>> Cheers,
>>> Francis
>>>
>>>
>>>> Oh okay. This is the commit that added the flag:
>>>>
>>>>
>>>> https://github.com/zeromq/libzmq/commit/779c37abc433cb6595ddeedaf86b280317656bdd
>>>>
>>>> libzmq was 4.1 at the time I believe.
>>>>
>>>> I'll probably look at it this week-end then :)
>>>>
>>>> On Mon, Nov 24, 2014 at 12:10 PM, Francis Le Bourse
>>>>  wrote:
>>>>>
>>>>> Hi,
>>>>> On 11/24/2014 11:35 AM, Arnaud Kapp wrote:
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> I recently added support for POLLPRI flag.
>>>>>> It looks like it's not handled in your patch
>>>>>
>>>>> No, it isn't handled. In which version do you have added this flag ?
>>>>> Currently, the patch is written for 3.2.4. I'll wait to put it in
>>>>> libzmq
>>>>> master.
>>>>>>
>>>>>> and that it needs custom
>>>>>> support. Since there is no test related to this flags you wouldn't
>>>>>> notice.
>>>>>>
>>>>>> I can give it a look if you want.
>>>>>
>>>>> That would be nice.
>>>>>
>>>>> Cheers,
>>>>> Francis
>>>>>
>>>>>
>>>>>> On Sat, Nov 22, 2014 at 2:16 PM, Pieter Hintjens 
>>>>>> wrote:
>>>>>>>
>>>>>>> I suggest you send the patch to libzmq master, and ensure all test
>>>>>>> cases pass. Then we can get this into the next version.
>>>>>>>
>>>>>>> On Fri, Nov 21, 2014 at 2:50 PM, Francis Le Bourse
>>>>>>>  wrote:
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> On 11/6/2014 3:18 PM, Pieter Hintjens wrote:
>>>>>>>>>
>>>>>>>>> Oh, ok. Sounds like you have a good candidate for some before/after
>>>>>>>>> measurement and optimization. Are you going to try to make a patch
>>>>>>>>> for
>>>>>>>>> this?
>>>>>>>>
>>>>>>>> I have a patch candidate for this optimization, the performance
>>>>>>>> improvement
>>>>>>>> is very good and it doesn't seem to introduce any new instability.
>>>>>>>> What is modified:
>>>>>>>>- zmq_poll(), there is only one poll() now,
>>>>>>>>- and epoll() from epoll.cpp
>>>>>>>> Other calls to poll() and select() are left unmodified.
>>>>>>>>
>>>>>>&g

Re: [zeromq-dev] zmq_poll performance question

[Arnaud Kapp]

Hello,

Sorry it took me a while, but I finally go to test your patch.
My setup that use POLLPRI seems to work properly with your patch applied :).

Did you submit a PR to get it merged into libzmq master yet?

On Fri, Nov 28, 2014 at 11:35 AM, Francis Le Bourse
 wrote:
>
> On 11/24/2014 8:08 PM, Arnaud Kapp wrote:
>>>
>>> Currently, the patch is written for 3.2.4. I'll wait to put it in libzmq
>>> master
>
> The first patch for 3.2.4 had an issue in zmq_poll(), I had tried a little
> too aggressive optimization by bypassing the "first_pass" processing. It is
> fixed in the current one.
> The patch for the current head is clean.
> Cheers,
> Francis
>
>
>> Oh okay. This is the commit that added the flag:
>>
>> https://github.com/zeromq/libzmq/commit/779c37abc433cb6595ddeedaf86b280317656bdd
>>
>> libzmq was 4.1 at the time I believe.
>>
>> I'll probably look at it this week-end then :)
>>
>> On Mon, Nov 24, 2014 at 12:10 PM, Francis Le Bourse
>>  wrote:
>>>
>>> Hi,
>>> On 11/24/2014 11:35 AM, Arnaud Kapp wrote:
>>>>
>>>> Hello,
>>>>
>>>> I recently added support for POLLPRI flag.
>>>> It looks like it's not handled in your patch
>>>
>>> No, it isn't handled. In which version do you have added this flag ?
>>> Currently, the patch is written for 3.2.4. I'll wait to put it in libzmq
>>> master.
>>>>
>>>>and that it needs custom
>>>> support. Since there is no test related to this flags you wouldn't
>>>> notice.
>>>>
>>>> I can give it a look if you want.
>>>
>>> That would be nice.
>>>
>>> Cheers,
>>> Francis
>>>
>>>
>>>> On Sat, Nov 22, 2014 at 2:16 PM, Pieter Hintjens  wrote:
>>>>>
>>>>> I suggest you send the patch to libzmq master, and ensure all test
>>>>> cases pass. Then we can get this into the next version.
>>>>>
>>>>> On Fri, Nov 21, 2014 at 2:50 PM, Francis Le Bourse
>>>>>  wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> On 11/6/2014 3:18 PM, Pieter Hintjens wrote:
>>>>>>>
>>>>>>> Oh, ok. Sounds like you have a good candidate for some before/after
>>>>>>> measurement and optimization. Are you going to try to make a patch
>>>>>>> for
>>>>>>> this?
>>>>>>
>>>>>> I have a patch candidate for this optimization, the performance
>>>>>> improvement
>>>>>> is very good and it doesn't seem to introduce any new instability.
>>>>>> What is modified:
>>>>>>   - zmq_poll(), there is only one poll() now,
>>>>>>   - and epoll() from epoll.cpp
>>>>>> Other calls to poll() and select() are left unmodified.
>>>>>>
>>>>>> I woulld be happy to have any feedback.
>>>>>>
>>>>>>
>>>>>> Cheers,
>>>>>> Francis
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Nov 6, 2014 at 2:09 PM, Francis Le Bourse
>>>>>>>  wrote:
>>>>>>>>
>>>>>>>> On 11/6/2014 11:47 AM, Pieter Hintjens wrote:
>>>>>>>>>
>>>>>>>>> A simple optimization is, when you are polling sockets for input,
>>>>>>>>> to
>>>>>>>>> continue reading from an active socket using a non-blocking read.
>>>>>>>>> So
>>>>>>>>> you process all waiting messages on a socket and then only switch
>>>>>>>>> back
>>>>>>>>> to poll when needed.
>>>>>>>>
>>>>>>>> Thank you for you quick reply.
>>>>>>>>
>>>>>>>> Yes, but the question was more about the zmq_poll() internals.
>>>>>>>> For 600+ file descriptors, zmq_poll() calls poll() a huge number of
>>>>>>>> times
>>>>>>>> for only a few that will trigger a POLLIN and the relevant
>>>>>>>> information
>>>>>>>> is
>>>>>>>> already known / present in the pollfds array. The

Re: [zeromq-dev] [zmqpp] Creating a documentation repo

[Arnaud Kapp]

It makes thing simpler indeed. I was worried about the repo growing in size and 
my tests were wrong:
I calculated ~50MB of docs while its ~10MB.

I guess I will go for in-repo doc then.
Thanks for feedback and for making re-do my size test.

On 11/30/2014 08:43 AM, Pieter Hintjens wrote:
> In other projects we push the generated docs into the development
> repo. It does make things simpler and so far no-one has raised
> "pollutes the main repo" as a problem. I'd keep things as simple as
> you can.
>
> -Pieter
>
> On Sat, Nov 29, 2014 at 10:30 PM, Arnaud Kapp  wrote:
> > Hello,
> >
> > A while ago I asked about using gh-pages to host zmqpp documentation.
> > I now realize it's a rather bad idea because the size of the generated
> > documentation is quite big, and would have polluted the repo.
> >
> > I'm playing around with Travis and a script to generate documentation
> > and push it anytime a build runs (unless it's a PR).
> >
> > To not pollute the development repo it would require a dedicated
> > documentation-only repository. The intent for this repo is to host
> > generated documentation, nothing more. We could delete/recreate in
> > case it eventually becomes too big.
> >
> > Does anyone oppose the creation of a zmqpp-doc repository inside the
> > zeromq organization, or does any one have a better alternative?
> >
> > Thank you,
> >
> > --
> > Kapp Arnaud - Xaqq
> > ___
> > 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
>

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

[zeromq-dev] [zmqpp] Creating a documentation repo

[Arnaud Kapp]

Hello,

A while ago I asked about using gh-pages to host zmqpp documentation.
I now realize it's a rather bad idea because the size of the generated
documentation is quite big, and would have polluted the repo.

I'm playing around with Travis and a script to generate documentation
and push it anytime a build runs (unless it's a PR).

To not pollute the development repo it would require a dedicated
documentation-only repository. The intent for this repo is to host
generated documentation, nothing more. We could delete/recreate in
case it eventually becomes too big.

Does anyone oppose the creation of a zmqpp-doc repository inside the
zeromq organization, or does any one have a better alternative?

Thank you,

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

Re: [zeromq-dev] XPub welcome message and manual subscriptions

[Arnaud Kapp]

Upon closer reading, it looks like you made the topic of the welcome
message customizable.

You can ignore my previous email.

Thanks for the new features.

On Wed, Nov 26, 2014 at 4:39 PM, Arnaud Kapp  wrote:
> Hello,
>
> This looks like a nice addition. I have one (little) problem with the
> "welcome message" feature. If I read correctly, the topic for
> receiving welcome message is "W". I think this is too short and too
> general.
>
>  Maybe we could use some "internal-looking" name, something like
> "__zmq_xpub_welcome" to make sure subscribing to welcome messages wont
> enable other unwanted subscriptions.
> This is because, correct me if i'm wrong, subscribing to "W" will
> enable subscriptions for "Woohoo" or stuff like this).
>
> Thoughts?
>
> On Wed, Nov 26, 2014 at 2:30 PM, Doron Somech  wrote:
>> Hi All,
>>
>> Just want to let you know and have a discussion on two features (two
>> solutions to problems) that I have just added to zeromq:
>>
>> Manual Subscriptions:
>> Publisher can be configured to manual mode, with manual mode subscriptions
>> send from the client are not added automatically (nor unsubscriptions) and
>> user must call set socket option with ZMQ_SUBSCRIBE on the publisher side to
>> confirm them.
>>
>> The idea is that now subscriptions can be confirmed according to
>> credentials, another use is to actually use a token for the subscription and
>> the publisher will translate the token to one or more topics. For the second
>> use the subscriber side must be of type xsub to avoid filtering messages on
>> the client side.
>>
>> You can take a look at the test for usage:
>> https://github.com/zeromq/libzmq/blob/master/tests/test_xpub_manual.cpp.
>>
>> Welcome message:
>> Publisher can be configured to send welcome message when subscriber is
>> attached.
>>
>> This solves the problem of not knowing if the connect action succeed, after
>> connecting we wait for X seconds for a welcome message, if not arrived we
>> know the publisher is down.
>>
>> I know this can also be solved with heartbeat but then you have to wait up
>> to the heartbeat interval (and probably double the interval to make sure).
>>
>> Another nice use it to find the closest publisher, if I have multiple
>> publishers around the world client can try to connect to all, the first one
>> to answer with welcome is probably the closest one (alternative to geodns).
>>
>> When using the welcome feature the client must subscribe for the welcome
>> message before trying to connect and server must use xpub, poll for incoming
>> subscriptions and read them(subscriptions can be ignored).
>>
>> You can take a look at the test for usage:
>> https://github.com/zeromq/libzmq/blob/master/tests/test_xpub_welcome_msg.cpp
>>
>>
>> Regards,
>>
>> Doron
>>
>> ___
>> zeromq-dev mailing list
>> zeromq-dev@lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
>
>
>
> --
> Kapp Arnaud - Xaqq



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

Re: [zeromq-dev] XPub welcome message and manual subscriptions

[Arnaud Kapp]

Hello,

This looks like a nice addition. I have one (little) problem with the
"welcome message" feature. If I read correctly, the topic for
receiving welcome message is "W". I think this is too short and too
general.

 Maybe we could use some "internal-looking" name, something like
"__zmq_xpub_welcome" to make sure subscribing to welcome messages wont
enable other unwanted subscriptions.
This is because, correct me if i'm wrong, subscribing to "W" will
enable subscriptions for "Woohoo" or stuff like this).

Thoughts?

On Wed, Nov 26, 2014 at 2:30 PM, Doron Somech  wrote:
> Hi All,
>
> Just want to let you know and have a discussion on two features (two
> solutions to problems) that I have just added to zeromq:
>
> Manual Subscriptions:
> Publisher can be configured to manual mode, with manual mode subscriptions
> send from the client are not added automatically (nor unsubscriptions) and
> user must call set socket option with ZMQ_SUBSCRIBE on the publisher side to
> confirm them.
>
> The idea is that now subscriptions can be confirmed according to
> credentials, another use is to actually use a token for the subscription and
> the publisher will translate the token to one or more topics. For the second
> use the subscriber side must be of type xsub to avoid filtering messages on
> the client side.
>
> You can take a look at the test for usage:
> https://github.com/zeromq/libzmq/blob/master/tests/test_xpub_manual.cpp.
>
> Welcome message:
> Publisher can be configured to send welcome message when subscriber is
> attached.
>
> This solves the problem of not knowing if the connect action succeed, after
> connecting we wait for X seconds for a welcome message, if not arrived we
> know the publisher is down.
>
> I know this can also be solved with heartbeat but then you have to wait up
> to the heartbeat interval (and probably double the interval to make sure).
>
> Another nice use it to find the closest publisher, if I have multiple
> publishers around the world client can try to connect to all, the first one
> to answer with welcome is probably the closest one (alternative to geodns).
>
> When using the welcome feature the client must subscribe for the welcome
> message before trying to connect and server must use xpub, poll for incoming
> subscriptions and read them(subscriptions can be ignored).
>
> You can take a look at the test for usage:
> https://github.com/zeromq/libzmq/blob/master/tests/test_xpub_welcome_msg.cpp
>
>
> Regards,
>
> Doron
>
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>



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

Re: [zeromq-dev] zmq_poll performance question

[Arnaud Kapp]

> Currently, the patch is written for 3.2.4. I'll wait to put it in libzmq 
> master

Oh okay. This is the commit that added the flag:
https://github.com/zeromq/libzmq/commit/779c37abc433cb6595ddeedaf86b280317656bdd

libzmq was 4.1 at the time I believe.

I'll probably look at it this week-end then :)

On Mon, Nov 24, 2014 at 12:10 PM, Francis Le Bourse
 wrote:
> Hi,
> On 11/24/2014 11:35 AM, Arnaud Kapp wrote:
>>
>> Hello,
>>
>> I recently added support for POLLPRI flag.
>> It looks like it's not handled in your patch
>
> No, it isn't handled. In which version do you have added this flag ?
> Currently, the patch is written for 3.2.4. I'll wait to put it in libzmq
> master.
>>
>>   and that it needs custom
>> support. Since there is no test related to this flags you wouldn't
>> notice.
>>
>> I can give it a look if you want.
>
> That would be nice.
>
> Cheers,
> Francis
>
>
>>
>> On Sat, Nov 22, 2014 at 2:16 PM, Pieter Hintjens  wrote:
>>>
>>> I suggest you send the patch to libzmq master, and ensure all test
>>> cases pass. Then we can get this into the next version.
>>>
>>> On Fri, Nov 21, 2014 at 2:50 PM, Francis Le Bourse
>>>  wrote:
>>>>
>>>> Hi,
>>>>
>>>> On 11/6/2014 3:18 PM, Pieter Hintjens wrote:
>>>>>
>>>>> Oh, ok. Sounds like you have a good candidate for some before/after
>>>>> measurement and optimization. Are you going to try to make a patch for
>>>>> this?
>>>>
>>>> I have a patch candidate for this optimization, the performance
>>>> improvement
>>>> is very good and it doesn't seem to introduce any new instability.
>>>> What is modified:
>>>>  - zmq_poll(), there is only one poll() now,
>>>>  - and epoll() from epoll.cpp
>>>> Other calls to poll() and select() are left unmodified.
>>>>
>>>> I woulld be happy to have any feedback.
>>>>
>>>>
>>>> Cheers,
>>>> Francis
>>>>>
>>>>>
>>>>> On Thu, Nov 6, 2014 at 2:09 PM, Francis Le Bourse
>>>>>  wrote:
>>>>>>
>>>>>> On 11/6/2014 11:47 AM, Pieter Hintjens wrote:
>>>>>>>
>>>>>>> A simple optimization is, when you are polling sockets for input, to
>>>>>>> continue reading from an active socket using a non-blocking read. So
>>>>>>> you process all waiting messages on a socket and then only switch
>>>>>>> back
>>>>>>> to poll when needed.
>>>>>>
>>>>>> Thank you for you quick reply.
>>>>>>
>>>>>> Yes, but the question was more about the zmq_poll() internals.
>>>>>> For 600+ file descriptors, zmq_poll() calls poll() a huge number of
>>>>>> times
>>>>>> for only a few that will trigger a POLLIN and the relevant information
>>>>>> is
>>>>>> already known / present in the pollfds array. The performance hit is
>>>>>> there.
>>>>>>
>>>>>> Cheers,
>>>>>> Francis
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On Thu, Nov 6, 2014 at 11:28 AM, Francis Le Bourse
>>>>>>>  wrote:
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I am looking at a performance issue in zmq, when the number of
>>>>>>>> zsockets
>>>>>>>> /
>>>>>>>> file descriptors becomes large.
>>>>>>>> The relevant calls are:
>>>>>>>>poll+0x57
>>>>>>>>zmq_poll+0x2e3
>>>>>>>>zloop_start+0x1e8
>>>>>>>>main+0xb40
>>>>>>>>__libc_start_main+0xfd
>>>>>>>> immediately followed by a loop of
>>>>>>>>poll+0x57
>>>>>>>>zmq::signaler_t::wait(int)+0x33
>>>>>>>>zmq::mailbox_t::recv(zmq::command_t*, int)+0x78
>>>>>>>>zmq::socket_base_t::process_commands(int, bool)+0xbe
>>>>>>>>zmq::socket_base_t::getsockopt(int, void*, unsigned
>>>>>>>> long*)+0x135
>>>>>>>>zmq_getsockopt+0x75
>>>>>>>>zmq_poll+0x3da
>>>>>>>>zloop_start+0x1e8
>>>>>>>>main+0xb40
>>>>>>>>__libc_start_main+0xfd
>>>>>>>>
>>>>>>>> The code in the loop is executed once per file descriptor in the
>>>>>>>> initial
>>>>>>>> pollarray, redoing a poll() system call each time.
>>>>>>>> Is there a reason to proceed that way ?
>>>>>>>> Would be possible to reuse the results of the first poll() in order
>>>>>>>> to
>>>>>>>> bypass the second set of system calls ?
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Francis
>>>>>>>>
>>>>>>>>
>>>>>>>> ___
>>>>>>>> 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
>>
>>
>>
>
>



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

Re: [zeromq-dev] zmq_poll performance question

[Arnaud Kapp]

Hello,

I recently added support for POLLPRI flag.
It looks like it's not handled in your patch and that it needs custom
support. Since there is no test related to this flags you wouldn't
notice.

I can give it a look if you want.

On Sat, Nov 22, 2014 at 2:16 PM, Pieter Hintjens  wrote:
> I suggest you send the patch to libzmq master, and ensure all test
> cases pass. Then we can get this into the next version.
>
> On Fri, Nov 21, 2014 at 2:50 PM, Francis Le Bourse
>  wrote:
>> Hi,
>>
>> On 11/6/2014 3:18 PM, Pieter Hintjens wrote:
>>>
>>> Oh, ok. Sounds like you have a good candidate for some before/after
>>> measurement and optimization. Are you going to try to make a patch for
>>> this?
>>
>> I have a patch candidate for this optimization, the performance improvement
>> is very good and it doesn't seem to introduce any new instability.
>> What is modified:
>> - zmq_poll(), there is only one poll() now,
>> - and epoll() from epoll.cpp
>> Other calls to poll() and select() are left unmodified.
>>
>> I woulld be happy to have any feedback.
>>
>>
>> Cheers,
>> Francis
>>>
>>>
>>> On Thu, Nov 6, 2014 at 2:09 PM, Francis Le Bourse
>>>  wrote:

 On 11/6/2014 11:47 AM, Pieter Hintjens wrote:
>
> A simple optimization is, when you are polling sockets for input, to
> continue reading from an active socket using a non-blocking read. So
> you process all waiting messages on a socket and then only switch back
> to poll when needed.

 Thank you for you quick reply.

 Yes, but the question was more about the zmq_poll() internals.
 For 600+ file descriptors, zmq_poll() calls poll() a huge number of times
 for only a few that will trigger a POLLIN and the relevant information is
 already known / present in the pollfds array. The performance hit is
 there.

 Cheers,
 Francis



> On Thu, Nov 6, 2014 at 11:28 AM, Francis Le Bourse
>  wrote:
>>
>> Hi,
>>
>> I am looking at a performance issue in zmq, when the number of zsockets
>> /
>> file descriptors becomes large.
>> The relevant calls are:
>>   poll+0x57
>>   zmq_poll+0x2e3
>>   zloop_start+0x1e8
>>   main+0xb40
>>   __libc_start_main+0xfd
>> immediately followed by a loop of
>>   poll+0x57
>>   zmq::signaler_t::wait(int)+0x33
>>   zmq::mailbox_t::recv(zmq::command_t*, int)+0x78
>>   zmq::socket_base_t::process_commands(int, bool)+0xbe
>>   zmq::socket_base_t::getsockopt(int, void*, unsigned long*)+0x135
>>   zmq_getsockopt+0x75
>>   zmq_poll+0x3da
>>   zloop_start+0x1e8
>>   main+0xb40
>>   __libc_start_main+0xfd
>>
>> The code in the loop is executed once per file descriptor in the
>> initial
>> pollarray, redoing a poll() system call each time.
>> Is there a reason to proceed that way ?
>> Would be possible to reuse the results of the first poll() in order to
>> bypass the second set of system calls ?
>>
>> Cheers,
>> Francis
>>
>>
>> ___
>> 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



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

Re: [zeromq-dev] [Proposal] - JeroMQ to use Java 1.7

[Arnaud Kapp]

> There are no more public updates for it

Out of curiosity, is this also true for security updates?

> That alone should be motivation enough for the upgrade.

Yes I think I agree with you then, especially if its been end of lifed
more than a year ago now.

On 11/23/2014 12:35 AM, Trevor Bernard wrote:
>> What are the advantages of supporting >= 1.7 only (and thus dropping
>> support for 1.6) ? Are there benefits for the JeroMQ devs/maintainer?
> 
> It allows you to write code that looks like this:
> https://gist.github.com/trevorbernard/5311e1dcaaa074654a09
> 
> This is an experimental API I have been yak shaving. At some point I'm
> going to port ideas to JeroMQ/JZMQ. This will require min Java 7.
> 
>> I want to say, if its free to support 1.6 then we should support it.
>> However, if takes time to maintain it then I don't know.
> 
> Currently it's free but Java 6 was end of lifed in Feb 2013. There are
> no more public updates for it. That alone should be motivation enough
> for the upgrade.
> 
> -Trev
> ___
> 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

Re: [zeromq-dev] [Proposal] - JeroMQ to use Java 1.7

[Arnaud Kapp]

Hello,

I am not familiar with JeroMQ and not too much with Java, so take my
inputs carefully :P.

> but I accidently released v0.3.4 with Java 1.7 and it's proved not to be a 
> problem.
This is a good sign.


What are the advantages of supporting >= 1.7 only (and thus dropping
support for 1.6) ? Are there benefits for the JeroMQ devs/maintainer?

I want to say, if its free to support 1.6 then we should support it.
However, if takes time to maintain it then I don't know.

On Fri, Nov 21, 2014 at 5:00 PM, Trevor Bernard
 wrote:
> Hi,
>
> I propose we bump the minimum supported Java version to 1.7 since Java
> 6 is already end of life. Originally I was leary of doing this because
> I believed it would break peoples code but I accidently released
> v0.3.4 with Java 1.7 and it's proved not to be a problem.
>
> Thoughts?
>
> -Trevor
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev



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

Re: [zeromq-dev] zmqpp

[Arnaud Kapp]

Hello,

> would it be too much to ask for a few instructions on what to do in order to 
> get started and build zmqpp on Windows with Visual Studio 2013?

Certainly not, but sadly I have very few experience developing on
windows, and literally 0 experience using zmq/zmqpp on windows :(

Assuming you already got the libzmq part working on windows, I'd
recommend just pulling the zmqpp code and building it as a part of
your project/subproject. *Maybe* the CMakeLists can help you, I am not
sure.

So basically, if you can't / dont want to use CMake (or if it simlpy
doesn't work), just add the zmqpp source to your project and build
them along with your code.

It looks like a few project are doing this, so I guess it should work.


Hope this help, let us know if it doesn't work :)

On Sun, Nov 9, 2014 at 11:04 PM, Riskybiz  wrote:
>
> Arnaud,
>
> Thank you for the suggestion to use 
> https://github.com/zeromq/zmqpp .  I did previously consider using it but 
> could not build it on Windows.  It’s important that I’m able to use zeromq on 
> Windows and program in c++.  However upon your suggestion I looked again and 
> noticed the following:
>
>
>
> Allow building zmqpp with Microsoft Visual Studio
>
> Changed preprocessor if directives to use || and && operators instead of 
> words "and"/"or"
>
> Replaced noexcept definition (if not supported) with NOEXCEPT - C++11 
> standard forbids defining keywords and MSVC checks that even if the keyword 
> is not implemented (checks since version 12 (2013))
>
> Moved socket flags to source file to prevent linker warnings about duplicate 
> definitions
>
> Moved inet functions into zmqpp namespace to resolve overload conflicts with 
> system functions - windows provides an overload different only by the return 
> value and that is forbidden in C++
>
>
>
>
>
> I’d like to try using it; would it be too much to ask for a few instructions 
> on what to do in order to get started and build zmqpp on Windows with Visual 
> Studio 2013?
>
>
>
> Thanks again,
>
>
>
> Riskybiz.
>
>
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>



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

Re: [zeromq-dev] ROUTER & identity value.

[Arnaud Kapp]

Hello,

The identity is binary content. It may very well be non printable bytes,
which would explain why it has no problem mapping from router to dealer but
cannot be displayed.
On Linux, try running your program piped to "cat -e": ./a.out | cat -e  ;;
IIRC it will some non-printable char.

On an other note, if you're going to use ZMQ in a c++ codebase, let me
recommend https://github.com/zeromq/zmqpp !

On Sat, Nov 8, 2014 at 10:13 PM, Riskybiz  wrote:

> I’ve created this zeromq-4.0.4 MultiPartMessage.h
>  class in C++.  It functions nicely.
> However I cannot fathom one aspect of its behaviour……..
>
>
>
> When the receive constructor is called to receive a message off a ROUTER
> socket then the inbound message identity should be stored in the class
> member variable ‘id’ (circa line 161).  However whenever I use the
> getIdentity() method on either Windows 7 or Debian Wheezy to get the value
> then print the identity to the console window then there is nothing to see,
> just a blank.
>
>
>
> What baffles me is that when replying to the message I use the
> getIdentity() method of the received message to set the destination
> identity in the send constructor of a different class instance AND the
> message gets back through to the originator.
>
>
>
> So it’s possible to pass messages from DEALER to ROUTER put the
> MultiPartMessage in a queue and later send it back to the originating
> DEALER; but I cannot visualise the identity value in the console!
>
>
>
> Does anyone know why this should be?
>
>
>
> Perplexed.
>
>
>
> Riskybiz.
>
>
>
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>


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

Re: [zeromq-dev] CZMQ Coverity Scan

[Arnaud Kapp]

Hello,

Yeah I just received your request.
It's weird that you couldn't see the defect. While it's not public for
unlogged user, it should be available to anyone who logged in.

Project setting is this: "Project summary and defects are viewable in
read-only mode by all users".

On Sun, Oct 26, 2014 at 7:21 PM, Pieter Hintjens  wrote:

> Is there any way I can see the defects? I've requested access via that
> site. Shame it's not open by default. The analysis should not be private.
>
> On Sun, Oct 26, 2014 at 6:26 PM, William Martin <
> william.mar...@power-lan.com> wrote:
>
>> Hi,
>>
>> It's looks like a very nice tool. I have create some issue based on the
>> last report.
>> https://scan.coverity.com/projects/3263/view_defects
>>
>> Thanks,
>>
>> On Sun, Oct 26, 2014 at 4:36 PM, Arnaud Kapp  wrote:
>>
>>> Hello everyone,
>>>
>>> About a week ago I added CZMQ to Coverity Scan. For those who
>>> don't know, it's a rather powerful static code analyzer.
>>>
>>> Coverity integrates well with Github. You should be able to see the
>>> defects report here: https://scan.coverity.com/projects/3263 ,
>>> provided that you are logged in (you can log-in with Github).
>>>
>>> Note that this build was manually uploaded. However,
>>> Coverity supports Travis-Ci integration.
>>>
>>> The number of scan per week is limited (based on number of line of
>>> code). This best pratice is to create a "coverity-scan" branch
>>> and to push change regularly in order to trigger build.
>>>
>>> If you guys are interested I can come up with a PR that would
>>> change the .travis.yml file and enable this behavior. We would
>>> then have to push code to covery-scan branch from time to time.
>>>
>>> Then, if this proves useful, we could consider adding libzmq.
>>>
>>> Thanks,
>>> ___
>>> zeromq-dev mailing list
>>> zeromq-dev@lists.zeromq.org
>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>>
>>
>>
>>
>> --
>> William MARTIN
>> <http://www.power-lan.com/>
>> 15 rue de la Noé des Yonnières
>> 44850 Saint-Mars-du-Désert
>>
>> Email : william.mar...@power-lan.com
>> Tel : 02 85 52 12 74 - 06 49 23 59 68
>> Fax : 02 85 52 13 72
>>
>> ___
>> 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
>
>


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

[zeromq-dev] CZMQ Coverity Scan

[Arnaud Kapp]

Hello everyone,

About a week ago I added CZMQ to Coverity Scan. For those who
don't know, it's a rather powerful static code analyzer.

Coverity integrates well with Github. You should be able to see the 
defects report here: https://scan.coverity.com/projects/3263 ,
provided that you are logged in (you can log-in with Github).

Note that this build was manually uploaded. However,
Coverity supports Travis-Ci integration.

The number of scan per week is limited (based on number of line of 
code). This best pratice is to create a "coverity-scan" branch
and to push change regularly in order to trigger build.

If you guys are interested I can come up with a PR that would
change the .travis.yml file and enable this behavior. We would
then have to push code to covery-scan branch from time to time.

Then, if this proves useful, we could consider adding libzmq.

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

Re: [zeromq-dev] API break in 4.1.x

[Arnaud Kapp]

Hi Pieter,

I am currently using this feature. I realize that this
can be worked around by manually looking up a hashmap with the socket
identity as a key.
I am not sure if there is such a workaround if someone is monitoring a 
STREAM socket.

I'd suggest making this a configurable option instead of removing it.

On 10/25/2014 09:08 PM, Pieter Hintjens wrote:
> Hi all,
>
> We've noticed this commit broke the API in 4.1.x:
>
> mmit afb24b53e6d1fc39cd1b73be706b335ed5c7b6fb
> Author: Goswin von Brederlow 
> Date:   Fri Jan 17 23:21:42 2014 +0100
>
>  Add STREAM connect notification.
>  Adjust test cases to connection notification.
>  Increase error checking in test cases.
>
> This change breaks existing applications. Does anyone have an
> objection to either removing it, or making it a configurable socket
> option?
>
> -Pieter
>
> Ps. also, volunteers to clean this up?  :-)
> ___
> 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

Re: [zeromq-dev] Customizing Incoming Routing Strategy

[Arnaud Kapp]

Yeah I realized that while this maybe *could* be
implemented for inproc using tons of hacks, it would
make 0 sense for other transports.

I will keep using a single socket :)

On 10/23/2014 11:28 PM, Pieter Hintjens wrote:
> On Thu, Oct 23, 2014 at 9:55 PM, Arnaud Kapp  wrote:
>
>> Well, fair-queue does *not* behave like FIFO...
>
>> push1.send("msg2");
>> push2.send("msg3");
>
> Realize that each socket is an async object, so there's no guarantee
> of the order these sends. If you want fifo, you use a single socket.
>
> -Pieter
> ___
> 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

Re: [zeromq-dev] Customizing Incoming Routing Strategy

[Arnaud Kapp]

Well, fair-queue does *not* behave like FIFO.
Imagine this simple code (in pseudo-code).

sink = zmq_socket(ZMQ_PULL);
sink.bind("inproc://my-sink");

push1 = zmq_socket(ZMQ_PUSH);
push1.connect("inproc://my-sink");
push2 = zmq_socket(ZMQ_PUSH);
push2.connect("inproc://my-sink");

push1.send("msg1");
push1.send("msg2");
push2.send("msg3");

// Reading on "sink" will give this:
// msg1
// msg3
// msg2

A fifo strategy would give:
// msg1
// msg2
// msg3


On 10/23/2014 09:27 PM, Dorvin wrote:
> W dniu 2014-10-23 20:49, Arnaud Kapp pisze:
>> Hello,
>>
>> Most sockets have a fair-queued routing strategy for incoming messages,
>> and this makes a lot of sense *most* of the time.
>>
>> I would like to know if this behavior could be customized, for example
>> to achieve a FIFO incoming strategy.
>>
>
> It's behaving like FIFO. Otherwise it would not make sense. Imagine 2
> PUB sockets connecting to one SUB. If only one PUB would send all
> messages you would receive only first one and got blocked waiting for
> second socket to send something.
>
> Treat "fair-queued" as opposite to ...hmmm... "priority queuing" which
> would mean "process all messages from source A, then all messages from
> source B, then...".
>
>
> Cheers,
> Jarek
>
> ___
> 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

[zeromq-dev] Customizing Incoming Routing Strategy

[Arnaud Kapp]

Hello,

Most sockets have a fair-queued routing strategy for incoming messages,
and this makes a lot of sense *most* of the time.

I would like to know if this behavior could be customized, for example 
to achieve a FIFO incoming strategy.

I therefore have a few questions:
* Would that need lots of code change (assuming this isn't  already 
available) ?
* Am I the only one that could be interested in this
customization ability?
* Are there reasons against this?

Thank you,

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

Re: [zeromq-dev] CZMQ community & red cards

[Arnaud Kapp]

Hello everyone,

It seems I am a bit late but here is what I think.
I'm a bit sad that the discussed thread lead to this. I know discussion
have been heated recently and it would've been great if it were avoided.
But hey, it happens.

On the particular pull request I agree that it could have been worded
better, however this is somehow a false problem: when reviewing pull
request one's look at all the commit and the whole diff before merging.
If you want to take a quick look at what a PR changes, I think one should
look at the individual commit messages.

I also happen to group not-so-much related stuff into pull request so I may
be biased.

About the code change itself, I am not familiar enough with czmq (I mostly
write C++, dont' hate me :) ) to discuss the "store as ascii" but would
like to point out that in zmqpp we store integer in network byte order for
our push/pop functions. Maybe this is worth discussing (for consistency
reason), but this particular mail thread is probably the wrong place.


On Fri, Oct 17, 2014 at 1:16 AM, Pieter Hintjens  wrote:

> On Thu, Oct 16, 2014 at 6:30 PM, Goswin von Brederlow 
> wrote:
>
> > That is something the czmq maintainers are exceedingly bad at.
>
> Citation needed. You make exceedingly bad patches. Probably the worst
> I've seen from anyone in this community, and you have the audacity and
> nerve to blame other people for that. Thankfully your patches are on
> permanent record and part of CZMQ's history. This is the reason I
> merge them. Permanent record.
>
> >. One problem, one patch, one pull
> > request. Not two unrelated problems in a single pull request.
>
> Citation needed. This is not specified in C4.1. Github does not work
> like that. We have never worked like that. You are inventing a rule to
> suit your style of working, and then (since you apparently do not like
> reading the rules) imagining it into reality.
>
> You have not accepted any criticism at all. You show no regret, or
> apology. Indeed, you deflect and blame others for your disturbing lack
> of social awareness. Whether your intention is to deliberately create
> damage and stress, or whether this is unintentional, does not matter.
> Outcomes matter, and the outcome here is that your contributions are
> not worth the difficulty of dealing with you.
>
> It is clear from your behavior, which now includes brigading our
> forums with strangers who have no status here, that you will continue
> on this path until either we submit to your bullying, or we eject you
> by force. You are not as unique as you might think, and your behavior
> is both familiar and predictable.
>
> This community is not aggressive, but I will be, when people like you
> threaten the peaceful and constructive process we have built. I think
> it has been a few years since I had to do this, so consider yourself
> "special". You can put this onto your CV.
>
> **You are as of now banned from this list, from CZMQ and all other
> projects I'm a founder of.**
>
> So decided, so executed.
>
> -Pieter
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>



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

Re: [zeromq-dev] ZeroMQ releases (3.2.5, 4.0.5, 4.1.0)

[Arnaud Kapp]

Hello,

The API documentation pages for 4-0, 4-1 and 4-2 are broken. HTML
formatting is off for some reason.
Maybe this is related this release, I don't really know how the website
updates work.

On Tue, Oct 14, 2014 at 3:15 PM, Holger Joukl  wrote:

> zeromq-dev-boun...@lists.zeromq.org schrieb am 14.10.2014 11:08:26:
>
> > Von: Pieter Hintjens
> > [...]
> > - 4.1.0 rc1, with many changes
> >
> > All on http://zeromq.org/intro:get-the-software as usual.
> >
> > Also:
> >
> > * The stabilization fork for 4.1.x is at
> https://github.com/zeromq/zeromq4-1
> > ...
>
> https://github.com/zeromq/zeromq4-1/blob/master/NEWS says:
> "
> ...
>
>  0MQ version 4.1.0 rc1, released on 2014/10/14
>
>  =
>
>
>
>  * Many changes, see ChangeLog.
>
>
> ...
> "
> Is there some dedicated ChangeLog or does this mean the commit
> history of https://github.com/zeromq/zeromq4-1?
>
> Best,
> Holger
>
> Landesbank Baden-Wuerttemberg
> Anstalt des oeffentlichen Rechts
> Hauptsitze: Stuttgart, Karlsruhe, Mannheim, Mainz
> HRA 12704
> Amtsgericht Stuttgart
>
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>



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

[zeromq-dev] Is my use case viable?

[Arnaud Kapp]

Hello everyone,

Not too long ago I asked about POLLPRI being handled by ZMQ for a
particular project i'm working on. I am still figuring out if ZMQ would be
a good fit in this project. I would like your feedback about my use case,
and your insight about performance problems I may encounter.

I've read that when using ZMQ one shouldn't have to spawn many sockets.
However, when thinking about my design I realized I'd be having a lot of
socket talking to each other (locally, through inproc://).

Each component of the software would somehow be like a ZActor. The a pipe
socket back to parent thread, a REP socket for other component to connect
to, and a PUB socket to publish event. (With an average of 100 component --
each with no "cpu intensive task"). The breakdown in multiple actor thread
would be for clarity, not performance (not all target computer have more
than 1 thread anyway).

I'd say a worst case scenario would around 500 - 1000 sockets. It should be
less than that most of the time though.

The messages activity is not stable. Most of the time I wouldn't expect
more than a dozen message per second being sent, but sometimes it would be
more. (300 - 400msg per seconds being published, plus the "control traffic"
through REQ/REP).

This software target low performance ARM device (raspberry pi mostly). I
know its not easy to tell based on what I just wrote, but do you think I
risk performance problem?
Do you think the design is "zmq approved" ?

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

[zeromq-dev] Support for POLLPRI flag

[Arnaud Kapp]

Hello,

I'd like to use the zmq_poll() function to monitor both zmq's sockets and
file descriptor.
My use case is monitoring GPIO pins (through /sys/class/gpio/*).

The think is, to monitor interrupt on the GPIO pins, the POLLPRI flags
needs to be passed to poll(). This doesn't seem to be implemented in ZMQ.

Is there a particular reason why this wasn't implemented, like portability
(i am not sure there is a similar think on Windows for example).

Thanks,

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