Re: [zeromq-dev] Defaulting to tweetnacl?

2016-02-11 Thread Benjamin Henrion
On Thu, Feb 11, 2016 at 9:36 AM, MinRK  wrote:
> I think tweetnacl by default makes sense.

+1

--
Benjamin Henrion 
FFII Brussels - +32-484-566109 - +32-2-3500762
"In July 2005, after several failed attempts to legalise software
patents in Europe, the patent establishment changed its strategy.
Instead of explicitly seeking to sanction the patentability of
software, they are now seeking to create a central European patent
court, which would establish and enforce patentability rules in their
favor, without any possibility of correction by competing courts or
democratically elected legislators."
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev


Re: [zeromq-dev] Defaulting to tweetnacl?

2016-02-11 Thread MinRK
I think tweetnacl by default makes sense.

On Wed, Feb 10, 2016 at 11:40 PM, Pieter Hintjens  wrote:

> Hi all,
>
> I'd like to start moving to tweetnacl as the default when building
> libzmq. This means, no separate install of libsodium, and encryption
> built in by default. We can still have a --with-libsodium and
> --without-curve at configure time.
>
> Does anyone have a problem with this? It will not change anything
> significant in terms of performance nor interoperability. Just easier
> builds.
>
> -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] Access to underlying Linux socket?

2016-02-11 Thread Mark Gillott
On Wed, 2016-02-10 at 23:33 +, Luca Boccassi wrote:
> On Feb 10, 2016 20:39, "Mark Gillott"  wrote:
> >
> > On Wed, 2016-02-10 at 20:45 +0100, Pieter Hintjens wrote:
> > > You can't do this really, since one ZeroMQ socket can map to 0..n
> > > system sockets.
> > >
> >
> > Had a feeling that was going to be the case.
> >
> > > There is a new option on libzmq master that lets you pre-configure
> a
> > > FD and give it to ZeroMQ to use for its first pipe. (ZMQ_USE_FD).
> > >
> >
> > Care to expand a bit more? Is there something (test code? source
> module)
> > you can point me at?
> 
> I can point you to the guy who developed that option. He sits a few
> meters from you in the same office and he has an awesome beard. :-)
> 

Is that the Italian guy who likes to add chicken to his pizza? :-).

> > > A custom hook to configure new sockets is a nice idea.
> > >
> >
> > So you register a hook with a newly created socket and you would get
> a
> > callback just prior to any bind/connect. Is that the idea? In czmq
> > terms, something like:
> >
> > s = zsock_new(ZMQ_REP)
> > zsock_configure(s, myfunc, myarg)
> > zsock_bind(s)
> >
> > The callback would be provided with the base socket?
> 
> Nice. That could work because all actual system sockets are created
> after bind/connect. And in CZMQ we could add a global zys switch that
> applies it automatically to all sockets to make it more convenient.
> 
> But the problem is that such callback should be executed for all
> sockets, be they TCP or IPC or inproc. So, there needs to be a way to
> discriminate somehow, as what you can do with the FD varies wildly.
> 
> It could be left to the application developer to be careful, but I
> think that's confusing and likely to cause troubles.
> 

Rather than a global callback, couldn't you attach the callback to
individual sockets?

Catch you later (if you're still talking to me!),

Mark

> Kind regards,
> Luca Boccassi
> 

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


Re: [zeromq-dev] Defaulting to tweetnacl?

2016-02-11 Thread Luca Boccassi
Hi,

I'm looking at it.

Kind regards,
Luca Boccassi

On 11 February 2016 at 17:30, Pieter Hintjens  wrote:
> BTW I've also broken Travis builds, as --with-tweetnacl is no longer valid.
>
> The correct model should be:
>
> - default build (uses tweetnacl)
> - libsodium bulld (separate)
>
> If no-one takes this on I'll give it a shot asap.
>
> -Pieter
>
> On Thu, Feb 11, 2016 at 6:22 PM, Pieter Hintjens  wrote:
>> Just a follow up, I've cleaned up the tweetnacl code, which was a bit
>> of a disaster.
>>
>> It's now in the src directory as tweetnacl.c and .h and conforms to
>> expectations of the rest of the codebase.
>>
>> -Pieter
>>
>> On Thu, Feb 11, 2016 at 9:40 AM, Benjamin Henrion  wrote:
>>> On Thu, Feb 11, 2016 at 9:36 AM, MinRK  wrote:
 I think tweetnacl by default makes sense.
>>>
>>> +1
>>>
>>> --
>>> Benjamin Henrion 
>>> FFII Brussels - +32-484-566109 - +32-2-3500762
>>> "In July 2005, after several failed attempts to legalise software
>>> patents in Europe, the patent establishment changed its strategy.
>>> Instead of explicitly seeking to sanction the patentability of
>>> software, they are now seeking to create a central European patent
>>> court, which would establish and enforce patentability rules in their
>>> favor, without any possibility of correction by competing courts or
>>> democratically elected legislators."
>>> ___
>>> 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


Re: [zeromq-dev] Access to underlying Linux socket?

2016-02-11 Thread Doron Somech
You can actually use monitoring for this. Event socket accepted. Maybe a
socket option that accept function that create the underlying socket.
On Feb 11, 2016 18:50, "Luca Boccassi"  wrote:

> On 11 February 2016 at 15:27, Doron Somech  wrote:
> > What is the specific option you need? Just make a socket option and apply
> > before connect. Like tcp keep alive and ipv6.
>
> Hi Doron,
>
> The problem is that, for the use case we have, we use it with an
> internal build of the Linux kernel, with additional options that are
> not merged upstream yet.
>
> We could simply maintain an internal patch, but we are thinking that
> if we can find a nice, general solution that could be useful for
> everyone, it would be better :-)
>
> Kind regards,
> Luca Boccassi
>
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev


Re: [zeromq-dev] Multi subscribe and single unsubscribe

2016-02-11 Thread Axel Voitier
That is the expected behaviour, yes.
Subscriptions are said to be additive and idempotent. That is, if you
subscribe twice to the same topic you have to unsubscribe twice to stop
receiving it (provided it is not matched by another subscribe).


Cheers,
Axel

--
Contact: axel.voit...@gmail.com
Secure: axel.voit...@protonmail.ch

2016-02-11 12:17 GMT+01:00 Navneet Kumar :

> Hello everyone,
>
> I was testing with PUB-SUB and found that
> When I subscribe to a topic twice, then unsubscribe once,
> and again subscribe I receive all messages.
> Messages queued at the PUB when I unsubscribed only once.
>
> However if I unsubscribe twice or subscribe only once and unsubscribe once.
> I will get messages only after the next subscribe.
>
> I wanted to know the internal mechanism of how the PUB handles
> multiple subscribe and unsubscribe messages and when does it
> queue messages for the client.
>
>
> Thanks
> --
> Navneet Kumar
>
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev


Re: [zeromq-dev] Access to underlying Linux socket?

2016-02-11 Thread Luca Boccassi
On 11 February 2016 at 09:32, Mark Gillott  wrote:
> On Wed, 2016-02-10 at 23:33 +, Luca Boccassi wrote:
>> On Feb 10, 2016 20:39, "Mark Gillott"  wrote:
>> >
>> > On Wed, 2016-02-10 at 20:45 +0100, Pieter Hintjens wrote:
>> > > You can't do this really, since one ZeroMQ socket can map to 0..n
>> > > system sockets.
>> > >
>> >
>> > Had a feeling that was going to be the case.
>> >
>> > > There is a new option on libzmq master that lets you pre-configure
>> a
>> > > FD and give it to ZeroMQ to use for its first pipe. (ZMQ_USE_FD).
>> > >
>> >
>> > Care to expand a bit more? Is there something (test code? source
>> module)
>> > you can point me at?
>>
>> I can point you to the guy who developed that option. He sits a few
>> meters from you in the same office and he has an awesome beard. :-)
>>
>
> Is that the Italian guy who likes to add chicken to his pizza? :-).

Still better than deep fried mars bars!

>> > > A custom hook to configure new sockets is a nice idea.
>> > >
>> >
>> > So you register a hook with a newly created socket and you would get
>> a
>> > callback just prior to any bind/connect. Is that the idea? In czmq
>> > terms, something like:
>> >
>> > s = zsock_new(ZMQ_REP)
>> > zsock_configure(s, myfunc, myarg)
>> > zsock_bind(s)
>> >
>> > The callback would be provided with the base socket?
>>
>> Nice. That could work because all actual system sockets are created
>> after bind/connect. And in CZMQ we could add a global zys switch that
>> applies it automatically to all sockets to make it more convenient.
>>
>> But the problem is that such callback should be executed for all
>> sockets, be they TCP or IPC or inproc. So, there needs to be a way to
>> discriminate somehow, as what you can do with the FD varies wildly.
>>
>> It could be left to the application developer to be careful, but I
>> think that's confusing and likely to cause troubles.
>>
>
> Rather than a global callback, couldn't you attach the callback to
> individual sockets?
>
> Catch you later (if you're still talking to me!),

I propose both: the low-level library could have the basic feature of
per-socket callback, and the higher level binding in addition could
provide a global setting for convenience.

Kind regards,
Luca Boccassi
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev


[zeromq-dev] Multi subscribe and single unsubscribe

2016-02-11 Thread Navneet Kumar
Hello everyone,

I was testing with PUB-SUB and found that
When I subscribe to a topic twice, then unsubscribe once,
and again subscribe I receive all messages.
Messages queued at the PUB when I unsubscribed only once.

However if I unsubscribe twice or subscribe only once and unsubscribe once.
I will get messages only after the next subscribe.

I wanted to know the internal mechanism of how the PUB handles
multiple subscribe and unsubscribe messages and when does it
queue messages for the client.


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


Re: [zeromq-dev] Multiplexing a TCP endpoint

2016-02-11 Thread Alex Bligh

On 10 Feb 2016, at 19:11, Tom Quarendon  wrote:

> This is what "resources" in ZMTP 3.1 were designed for. No implementation yet 
> though (see other discussion on his list) :-)

Thanks. That is pretty much exactly what I was looking for (other than the 'no 
implementation yet though' bit).

I've only just subscribed to the list and my google search through the archives 
led only to a post in 2013 hoping this would be in zeromq 4.0. Do you have a 
pointer to the discussion (e.g. the thread title)?

I've read the relevant part of the ZTMP specification. In essence the 
'resource' seems to be transmitted in the metadata when the connection is set 
up. I'm guessing to use this feature in a compatible way without implementation 
details, then:

1. On the 'connect' side, I'd merely need to add some metadata

2. On the 'bind' side, I'd need to run some form of multiplexer and look at the 
metadata property.

I can't however see an API way to set or read from the metadata dictionary 
before any messages are passed.

Am I therefore correct that it isn't possible to implement this without a 
change to zeromq itself?

> You would have to write the proxy loop yourself. So do a select on the 
> external socket and all the internal sockets and know that when you pull a 
> message from the external socket that you peel off the first frame after the 
> delimiter, then use the service name it includes to pick which internal 
> socket to pass the rest of the message to. The services then run 
> independently on their own inproc (or even out of process on ipc or tcp) 
> sockets. It's what I would end up doing to do the same thing. 

That's pretty much what I concluded save for the fact that I had thought the 
service ID should probably be the innermost frame (possibly after the empty 
frame delimiter and with it's own zero frame delimiter) so the transport over 
TCP could (if necessary) be routed transparently through RTR sockets.

-- 
Alex Bligh




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


Re: [zeromq-dev] Access to underlying Linux socket?

2016-02-11 Thread Mark Gillott
On Wed, 2016-02-10 at 23:33 +, Luca Boccassi wrote:
> > > There is a new option on libzmq master that lets you pre-configure
> a
> > > FD and give it to ZeroMQ to use for its first pipe. (ZMQ_USE_FD).
> > >
> >
> > Care to expand a bit more? Is there something (test code? source
> module)
> > you can point me at?
> 
> I can point you to the guy who developed that option. He sits a few
> meters from you in the same office and he has an awesome beard. :-)
> 

Many thanks Luca.

To close the loop on this. Luca & I talked and the ZMQ_USE_FD option
solves the issue for listener (bind) sockets. Unfortunately there needs
to be a different solution for when an application wants to set an
option prior to a ZeroMQ connect (need the option to be persistent
across "reconnects"). Kicking around a few ideas.

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


Re: [zeromq-dev] Access to underlying Linux socket?

2016-02-11 Thread Doron Somech
What is the specific option you need? Just make a socket option and apply
before connect. Like tcp keep alive and ipv6.
On Feb 11, 2016 15:12, "Mark Gillott"  wrote:

> On Wed, 2016-02-10 at 23:33 +, Luca Boccassi wrote:
> > > > There is a new option on libzmq master that lets you pre-configure
> > a
> > > > FD and give it to ZeroMQ to use for its first pipe. (ZMQ_USE_FD).
> > > >
> > >
> > > Care to expand a bit more? Is there something (test code? source
> > module)
> > > you can point me at?
> >
> > I can point you to the guy who developed that option. He sits a few
> > meters from you in the same office and he has an awesome beard. :-)
> >
>
> Many thanks Luca.
>
> To close the loop on this. Luca & I talked and the ZMQ_USE_FD option
> solves the issue for listener (bind) sockets. Unfortunately there needs
> to be a different solution for when an application wants to set an
> option prior to a ZeroMQ connect (need the option to be persistent
> across "reconnects"). Kicking around a few ideas.
>
> Mark
> ___
> 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] Access to underlying Linux socket?

2016-02-11 Thread Luca Boccassi
On 11 February 2016 at 15:27, Doron Somech  wrote:
> What is the specific option you need? Just make a socket option and apply
> before connect. Like tcp keep alive and ipv6.

Hi Doron,

The problem is that, for the use case we have, we use it with an
internal build of the Linux kernel, with additional options that are
not merged upstream yet.

We could simply maintain an internal patch, but we are thinking that
if we can find a nice, general solution that could be useful for
everyone, it would be better :-)

Kind regards,
Luca Boccassi
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev


Re: [zeromq-dev] Defaulting to tweetnacl?

2016-02-11 Thread Pieter Hintjens
Just a follow up, I've cleaned up the tweetnacl code, which was a bit
of a disaster.

It's now in the src directory as tweetnacl.c and .h and conforms to
expectations of the rest of the codebase.

-Pieter

On Thu, Feb 11, 2016 at 9:40 AM, Benjamin Henrion  wrote:
> On Thu, Feb 11, 2016 at 9:36 AM, MinRK  wrote:
>> I think tweetnacl by default makes sense.
>
> +1
>
> --
> Benjamin Henrion 
> FFII Brussels - +32-484-566109 - +32-2-3500762
> "In July 2005, after several failed attempts to legalise software
> patents in Europe, the patent establishment changed its strategy.
> Instead of explicitly seeking to sanction the patentability of
> software, they are now seeking to create a central European patent
> court, which would establish and enforce patentability rules in their
> favor, without any possibility of correction by competing courts or
> democratically elected legislators."
> ___
> 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] Defaulting to tweetnacl?

2016-02-11 Thread Pieter Hintjens
BTW I've also broken Travis builds, as --with-tweetnacl is no longer valid.

The correct model should be:

- default build (uses tweetnacl)
- libsodium bulld (separate)

If no-one takes this on I'll give it a shot asap.

-Pieter

On Thu, Feb 11, 2016 at 6:22 PM, Pieter Hintjens  wrote:
> Just a follow up, I've cleaned up the tweetnacl code, which was a bit
> of a disaster.
>
> It's now in the src directory as tweetnacl.c and .h and conforms to
> expectations of the rest of the codebase.
>
> -Pieter
>
> On Thu, Feb 11, 2016 at 9:40 AM, Benjamin Henrion  wrote:
>> On Thu, Feb 11, 2016 at 9:36 AM, MinRK  wrote:
>>> I think tweetnacl by default makes sense.
>>
>> +1
>>
>> --
>> Benjamin Henrion 
>> FFII Brussels - +32-484-566109 - +32-2-3500762
>> "In July 2005, after several failed attempts to legalise software
>> patents in Europe, the patent establishment changed its strategy.
>> Instead of explicitly seeking to sanction the patentability of
>> software, they are now seeking to create a central European patent
>> court, which would establish and enforce patentability rules in their
>> favor, without any possibility of correction by competing courts or
>> democratically elected legislators."
>> ___
>> 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