rk do have proprietary solutions.)
>
> -John
>
> On Fri, Jan 12, 2018 at 1:31 AM Laurent Alebarde <l.aleba...@free.fr
> <mailto:l.aleba...@free.fr>> wrote:
>
> Hi,
> I read in some places that in its infancy, 0MQ was aimed at high
> frequency
Hi,
I read in some places that in its infancy, 0MQ was aimed at high
frequency trading. From what I can read, this field first requirement is
on hardware, short links (proximity) and algorithm. I would like to
understand more please what makes 0MQ good for robust and rapid
transactions ?
Regards,
Hi,
That's more than two years I have not used 0MQ. I assume many things has
changed in the time between. Reviewing the change log, I have to dig in
the huge adds in the 4.1.0 rc1 release of October 2014.
I have moved professionaly and where I am now, they are used to using a
Java+JBoss|Tomcat
keys have been pre-distributed somehow may be performed with use of
the Diffie--Hellman key exchange algorithm:
http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange
Le 03/04/2014 10:23, Lindley French a écrit :
I don't know CURVE well, but in general, key management is a hard
I think you are right because ZMTP negociates the protocol with each
mechanism instance, and there is a mechanism instance for each connection.
But I am not sure.
Laurent
Le 01/04/2014 10:04, Goswin von Brederlow a écrit :
On Mon, Mar 31, 2014 at 09:27:20PM +0200, Laurent Alebarde wrote
Hi Greg,
As far as I know, encryption is per socket. So you can have one context,
and in this context, one CURVE socket for the wild, and one NULL socket
for your homeland.
Laurent
Le 31/03/2014 21:12, Greg Ward a écrit :
Hi all --
I'm helping maintain a ZeroMQ-based system that currently
I have used successfully pools of sockets when I need custom load
balancing between clients and workers, especially when I need a sticky
connection i.e. one client is associated to one worker for a full
session (several messages exchange). In this use case, connecting
several end-points to the
Due to the numerous accronyms used for 0MQ, I recommand using a ORing of
all when one looks for information about it.
For example, with google: (0mq|zeromq|zmq|libzmq).
BTW IMHO, in terms of efficiency, it would be nice to converge to only
one of them.
Laurent
My two cents:
Do architect your system roughly, then perform minimal tests of the
library features you expect to use, consider what's available in a
second choice library, then abstract what's useful for you in the
library of your choice in a layer of your own, keeping the second choice
in
for proxying the requests through the middleware.
Unfortunately this middleware makes it go from a clear cut picture to
very murky waters.
Dave
On 3/20/2014 6:04 AM, Laurent Alebarde wrote:
My two cents:
Do architect your system roughly, then perform minimal tests of the
library features you
for proxying the requests through the middleware.
Unfortunately this middleware makes it go from a clear cut picture to
very murky waters.
Dave
On 3/20/2014 6:04 AM, Laurent Alebarde wrote:
My two cents:
Do architect your system roughly, then perform minimal tests of the
library features you
Software is not about what's one likes or not, but about standards,
state of the art, rigorousness, and quality.
/Simplicity/ does not go always along /quality/, but /quality/ goes far
much often with /simplicity/.
IMHO, if the libzmq code was much quality and standards oriented, it
would
state of the art applies more to work, and actually not to art. But I
agree with you to the point personal style or preferences do not go
against coding rules.
Le 08/03/2014 23:54, Gregg Irwin a écrit :
Hi Laurent,
LA Software is not about what's one likes or not, but about standards,
LA
You are right. Possibly a bug in the lib ?
Le 24/02/2014 18:13, Olaf Mandel a écrit :
Am 24.02.2014 18:04, schrieb Laurent Alebarde:
By default, you are allowed 1024 sockets per context. After having
created the context, you shall increase the quantity of sockets allowed:
rc
Le 25/02/2014 21:08, Joe Lin a écrit :
I'm building a server that should support 100K+ concurrent users. A
user belongs to one or more groups and the number of groups would be
around 1/10 of the total users. Therefore there will be about 10K
groups. A user needs to be notified by the events
Where is your socket variable declaration ?
You shall use one variable per socket, so, use an array.
Le 24/02/2014 11:32, Olaf Mandel a écrit :
Hello,
I am currently trying to open and close many sockets and run into the
MAX_SOCKETS limit, even though only one socket should be open at a time.
Sorry, I didn't see you was closing the socket. Anyway, Diego's remark
looks right. So either add a sleep in your loop to enable the lib to
free the socket, either use an array.
Le 24/02/2014 12:12, Olaf Mandel a écrit :
Am 24.02.2014 11:43, schrieb Laurent Alebarde:
Where is your socket
By default, you are allowed 1024 sockets per context. After having
created the context, you shall increase the quantity of sockets allowed:
rc = zmq_ctx_set (ctx, ZMQ_MAX_SOCKETS, 1);
assert (rc == 0);
Le 24/02/2014 17:06, Olaf Mandel a écrit :
Am 24.02.2014 15:50,
As you are using LINGER, the sockets stays alive for the time specified.
In your test, where you want absolutly to use one variable, you shall
set LINGER to 0.
Le 24/02/2014 18:04, Laurent Alebarde a écrit :
By default, you are allowed 1024 sockets per context. After having
created
Hi Devs,
I am making tests on libzmq master. I have an issue when my test becomes
big with a lot of STREAM sockets.
The test is a client / server, the server is composed of a broker and
workers. I have a separate ctx for client (1 thread, 100 sockets), but
the same for workers (6 threads,
/ThomasHabets/monotonic_clock.
I doubt it is the cause of my problem, because my measure is around 1
minute, but I am going to try.
Le 18/02/2014 17:40, Lindley French a écrit :
It's possible the CPU isn't the bottleneck here?
On Tue, Feb 18, 2014 at 7:26 AM, Laurent Alebarde l.aleba...@free.fr
Hi Devs,
Here are some tests on a 8 cores cpu.
500 client sockets sending 100 requests each with CURVE.
The duration measured takes into account only the exchange phase (not
the preparation like sockets creation, bind, connect).
Clients sockets are polled and a new request is sent as soon as
limits. The work
will happen in the background I/O thread, not your application thread.
So start as many I/O threads as you have CPU cores. How you match
sockets to application threads is going to be insignificant.
On Thu, Feb 13, 2014 at 6:08 PM, Laurent Alebarde l.aleba...@free.fr wrote:
Hi all
The existing IDENTITY socket option is useless for your purpose because
it is transmitted at the end of the handcheck in the metadata. When a
ROUTER receives a new connection, it assigns to it a own forged identity
(random for the first peer and then incremented for the next ones). It
is a 5
The greeting's signature would be an easier place (8 bytes available).
Le 14/02/2014 09:50, Laurent Alebarde a écrit :
The existing IDENTITY socket option is useless for your purpose
because it is transmitted at the end of the handcheck in the metadata.
When a ROUTER receives a new connection
Hi Devs,
I wonder what is the internal behaviour of libzmq when a blocking
zmq_poll is used ws thread activation:
int rc = zmq_poll (items, 2, -1);
Does the libzmq internal I/O thread awake the user's thread only when
the poll has received an event ? Or are the user's thread that blocks on
Does the selftest test_security_curve pass ?
Le 14/02/2014 14:39, Drew Crawford a écrit :
Hello folks,
For some reason, a message sent from the REQ side of a REQ/ROUTER
isn't arriving. I know from experience this is some kind of CURVE
issue, but I have stared at my curve usage for several
.
If these assumptions are true, then
the solution is for the local socket to not ignore subsequent identity
data and instead modify its mapping.
Am I wrong in my assumptions?
On 02/14/2014 12:50 AM, Laurent Alebarde wrote:
The existing IDENTITY socket option is useless for your purpose because
I have to admit I have had a very hard time to achieve this.
Thanks again Goswin.
Laurent
Le 11/02/2014 10:02, Goswin von Brederlow a écrit :
On Mon, Feb 10, 2014 at 05:31:34PM +0100, Laurent Alebarde wrote:
Le 10/02/2014 10:43, Goswin von Brederlow a écrit :
On Thu, Feb 06, 2014 at 04:34
Hi all,
In a server, I want to assign one socket per client (CURVE). What is the
best in terms of performance ressources ? Say I want to deal with
1,000 simultaneous clients.
1. one socket per thread with an avarage cpu load 1%, and 1,000 threads ?
2. 100 sockets per thread with an avarage
Hi all,
I am designing an architecture with tens of workers, each with hundreds
of sockets. All the sockets connect to the same address. On the broker
point of view, nothing differentiates the connections it receives except
their unique identity it assigns to them. If it was one worker with
Le 11/02/2014 10:18, Goswin von Brederlow a écrit :
On Mon, Feb 10, 2014 at 05:38:44PM +0100, Laurent Alebarde wrote:
Le 10/02/2014 11:12, Goswin von Brederlow a écrit :
On Sun, Feb 09, 2014 at 12:16:48AM +0100, Laurent Alebarde wrote:
When I replace the tcp address tcp://127.0.0.1:5556
Le 11/02/2014 10:02, Goswin von Brederlow a écrit :
On Mon, Feb 10, 2014 at 05:31:34PM +0100, Laurent Alebarde wrote:
Le 10/02/2014 10:43, Goswin von Brederlow a écrit :
On Thu, Feb 06, 2014 at 04:34:03PM +0100, Laurent Alebarde wrote:
Hi Devs,
I wonder please what differentiates connected
Le 10/02/2014 10:43, Goswin von Brederlow a écrit :
On Thu, Feb 06, 2014 at 04:34:03PM +0100, Laurent Alebarde wrote:
Hi Devs,
I wonder please what differentiates connected peers on a ZMTP point
of view ?
To be more clear, let's consider this network:
Client 1 205.23.12.47
Le 10/02/2014 11:12, Goswin von Brederlow a écrit :
On Sun, Feb 09, 2014 at 12:16:48AM +0100, Laurent Alebarde wrote:
When I replace the tcp address tcp://127.0.0.1:5556 with an
*inproc* one, say inproc://testStream, in /tests/test_stream.cpp/,
the test fails. It asserts on
rc = zmq_recv
It seems that the cause is the use of ZMQ_STREAM with inproc ?
Le 08/02/2014 09:16, Laurent Alebarde a écrit :
Hi Devs,
I assume I have done something wrong, but I don't know what. Does
somebody has an idea what can cause such failure please ?
The context is a poll of three sockets:
void
Hi Devs,
The doc says: /CURVE is intended for use on public networks./, but it
does not say it does not work on other transport than tcp. Thought,
following the debugger, it appears that it is not activated with the
inproc transport. Moreover, the stream_engine where protocol
negotiations
threads in one process.
Over ipc:// conceivably, it could make sense.
On Sun, Feb 9, 2014 at 10:41 AM, Laurent Alebarde l.aleba...@free.fr wrote:
Hi Devs,
The doc says: CURVE is intended for use on public networks., but it does
not say it does not work on other transport than tcp. Thought
Hi Devs,
I assume I have done something wrong, but I don't know what. Does
somebody has an idea what can cause such failure please ?
The context is a poll of three sockets:
void *frontend = zmq_socket (ctx, ZMQ_ROUTER);
assert (frontend);
int rc = zmq_bind (frontend,
When I replace the tcp address tcp://127.0.0.1:5556 with an *inproc*
one, say inproc://testStream, in /tests/test_stream.cpp/, the test
fails. It asserts on
rc = zmq_recv (stream, buffer, 255, 0);
assert (rc == 0);
The documentation for sockets says: /A socket of type 'ZMQ_STREAM' is
Hi all,
Are ZMQ_PAIR sockets kinds of raw sockets, or do they fulfil the NULL,
PLAIN, CURVE mechanisms ?
Laurent
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Le 05/02/2014 13:46, Pieter Hintjens a écrit :
Thanks for the proposals changes,
And thanks for your great help.
To amend my debt, I propose you a patch to suppress duplicated code in
curve_server and curve_client, concerning the encode and decode
functions. I did that some months ago
No, the patch I wrote was against libzmq.
Le 07/02/2014 15:28, Pieter Hintjens a écrit :
Sounds nice. If you make that patch against libcurve, I'll merge it.
On Fri, Feb 7, 2014 at 10:35 AM, Laurent Alebarde l.aleba...@free.fr wrote:
Le 05/02/2014 13:46, Pieter Hintjens a écrit :
Thanks
21:
http://rfc.zeromq.org/spec:21
On Wed, Feb 5, 2014 at 6:43 PM, Laurent Alebarde l.aleba...@free.fr wrote:
Le 05/02/2014 12:51, Pieter Hintjens a écrit :
typedef struct zmq_proxy_open_chain_t {unsigned char _ [496];}
Again, seriously? Magic numbers? We do this for zmq_msg for
unfortunate
Done. I have squashed.
Le 06/02/2014 12:40, Pieter Hintjens a écrit :
Nice. The type for the API should be zmq_proxy_t. I hope you feel this
API style is clearer. It has helped our C code a lot.
On Thu, Feb 6, 2014 at 12:09 PM, Laurent Alebarde l.aleba...@free.fr wrote:
Thanks Pieter, I have
Hi Devs,
I wonder please what differentiates connected peers on a ZMTP point of
view ?
To be more clear, let's consider this network:
Client 1 205.23.12.47
Server
Client 2 102.12.88.254 --/
I know inproc connect first has been added no more than a few months
ago. So, yes, the doc misses an update.
Le 05/02/2014 10:35, Alex Pyrgiotis a écrit :
Hi all,
Reading the zeromq guide, I'm seeing the following statement regarding
the inproc transport protocol:
the server must issue a
On Tue, Feb 4, 2014 at 11:34 PM, Laurent Alebarde l.aleba...@free.fr wrote:
Hi Devs,
I have finished to develop zmq_proxy_open_chain. This one comes with a few
functions, in particular the one to sleep/awake a socket.
typedef struct zmq_proxy_open_chain_t {unsigned char _ [496
No problem for me. I am here just to share.
Le 05/02/2014 12:51, Pieter Hintjens a écrit :
On Wed, Feb 5, 2014 at 12:36 PM, Laurent Alebarde l.aleba...@free.fr wrote:
If you have another suggestion for 'zmq_proxy_open_chain' that makes more
sense for you, I will change it. But with my
Hi all,
I have added the *zmq_proxy_open_chain* family functions in my
repository here (branch proxy_open_chain_AllIn1):
https://github.com/lalebarde/libzmq/commit/4fc96a516b59e75138cb4c48cb569c14a855073d
It follows the functions zmq_proxy_steerable, zmq_proxy_hook, and
zmq_proxy_chain
Le 05/02/2014 12:51, Pieter Hintjens a écrit :
typedef struct zmq_proxy_open_chain_t {unsigned char _ [496];}
Again, seriously? Magic numbers? We do this for zmq_msg for
unfortunate historic reasons. It is _very bad_ API design.
Replaced by an opaque void pointer, eliminating this awful
Hi Devs,
I have finished to develop zmq_proxy_open_chain. This one comes with a
few functions, in particular the one to sleep/awake a socket.
typedef struct zmq_proxy_open_chain_t {unsigned char _ [496];}
zmq_proxy_open_chain_t;
ZMQ_EXPORT int zmq_proxy_open_chain_init
:46PM +0100, Laurent Alebarde wrote:
Hi Devs,
I assume every function in the libzmq API is thread safe, but there
are static variables in the code and no use of __thread ? Are all
static variables defined in libzmq global to all threads ?
If I add a static variable which need to be thread local, say
with a cool RD.
There is no legitimate reason to prevent anyone to get freedom and to
be, behave and work as he is, as far as the freedom and dignity of
everyone else is respected and preserved.
My 2 cts.
Laurent Alebarde
Le 30/01/2014 14:00, Pieter Hintjens a écrit :
On Thu, Jan 30, 2014 at 4:29
probably assert in such a case.
On Wed, Jan 29, 2014 at 12:07 PM, Laurent Alebarde l.aleba...@free.fr wrote:
Hi Devs,
What is the zmq_poll behaviour when the zmq_pollitem_t array contains an
item with a NULL socket ? ignored, undefined, error ?
If it is in src/poll.cpp / void zmq::poll_t::loop
.
Conclusion: I have to deal myself with the complexity of not having NULL
sockets in my zmq_pollitem_t array.
Le 30/01/2014 09:23, Laurent Alebarde a écrit :
Thanks Pieter.
Personnaly, I would prefer ignore, in order to build zmq_pollitem_t
arrays with more ease, when they are built
int fd;
#endif
} dev;
short events;
short revents;
} zmq_pollitem_t;
But it would break the ABI to change it, isn't it ?
Le 30/01/2014 10:56, Laurent Alebarde a écrit :
In fact, it is in src/zmq.cpp / int zmq_poll (zmq_pollitem_t *items_,
int nitems_, long timeout_)
When
Hi James,
As far as I have understood it, if you modify libzmq with some great
feature you pattent, then you are implicitly giving freely a licence to
all users of your libzmq version. But if your patent is on an
application of yours that makes use of libzmq, then it is alright.
With
, 2014, at 5:20 AM, Laurent Alebarde l.aleba...@free.fr
mailto:l.aleba...@free.fr wrote:
IMHO, it is a bad design of zmq_pollitem_t. It should not have one
attribute for socket and another one for file-descriptor with this
unrobust behaviour to use the second one when the first one is NULL,
but one
Hi all,
I have a test that makes zmq_disconnect and zmq_close fail (in the frame
of developments on libzmq itself, but besides that, all tests pass).
*Test 1:*
void *worker = zmq_socket (ctx, ZMQ_DEALER);
assert (worker);
int linger_time = 100;
//rc = zmq_setsockopt (worker,
Hi Devs,
I assume every function in the libzmq API is thread safe, but there are
static variables in the code and no use of __thread ? Are all static
variables defined in libzmq global to all threads ?
If I add a static variable which need to be thread local, say inside
zmq::proxy, is it
Hi Devs,
What is the*zmq_poll* behaviour when the*zmq_pollitem_t* array contains
an item with a NULL socket ? ignored, undefined, error ?
If it is in src/poll.cpp / void zmq::poll_t::loop () / for
(pollset_t::size_type i = 0; i != pollset.size (); i++), it seems there
is no NULL test with a
, Goswin von Brederlow a écrit :
On Tue, Jan 21, 2014 at 11:09:54AM +0100, Laurent Alebarde wrote:
Hi Devs,
This is my thuesday morning stupid question: say I have a socket on
which I send a message, and just after I put a receive on this same
socket in the code. What prevents in libzmq to receive
I have added a 100 ms LINGER to all sockets, but it does not change
anything.
https://github.com/lalebarde/libzmq/commit/e64498610ce8976b9cade226e415b7646a7d02b3
Le 28/01/2014 15:20, Laurent Alebarde a écrit :
Hi Devs,
I am working on a test derived from /test_proxy.cpp/ with the use
I forgot to close the two additional sockets of the test ! :-[
Sorry for the disturbance.
Le 28/01/2014 15:37, Laurent Alebarde a écrit :
I have added a 100 ms LINGER to all sockets, but it does not change
anything.
https://github.com/lalebarde/libzmq/commit
Hi all,
I have developped a proxy hook to ease the development of different
kinds of proxy for say filtering, tests, ROUTER/ROUTER proxy,
STREAM/STREAM proxy, etc. My first aim was to have something conveniant
for the development of a CURVE proxy (including the handcheck, to load
balance the
Hi Devs,
This is my thuesday morning stupid question: say I have a socket on
which I send a message, and just after I put a receive on this same
socket in the code. What prevents in libzmq to receive the message I
have just sent ?
Let's raise the question differently, what prevents
Le 21/01/2014 12:32, Goswin von Brederlow a écrit :
On Tue, Jan 21, 2014 at 11:09:54AM +0100, Laurent Alebarde wrote:
Hi Devs,
This is my thuesday morning stupid question: say I have a socket on
which I send a message, and just after I put a receive on this same
socket in the code. What
Le 21/01/2014 12:17, Goswin von Brederlow a écrit :
I played around with that and you can test it:
https://github.com/mrvn/libzmq/tree/mrvn
So far the code compiles (for me). I haven't had time to write a
proper test case for it yet. But I've modifed tests/test_security_curve.cpp
to call
Great, thanks Goswin.
Le 20/01/2014 10:34, Goswin von Brederlow a écrit :
On Sun, Jan 19, 2014 at 10:38:31AM +0100, Laurent Alebarde wrote:
Can a ZMQ_STREAM socket be put inside a zmq_pollitem_t structure,
like and along any other socket, to be zmq_poll-ed ?
Works for me. I'm polling 2
or contributions welcome.
Cheers,
Laurent.
Le 18/01/2014 16:08, Laurent Alebarde a écrit :
Le 18/01/2014 11:58, Goswin von Brederlow a écrit :
On Fri, Jan 17, 2014 at 11:40:13AM +0100, Laurent Alebarde wrote:
Hi Devs,
I am doing some experiments (cf at the end for the goal) and wonder
where I
Can a ZMQ_STREAM socket be put inside a zmq_pollitem_t structure, like
and along any other socket, to be zmq_poll-ed ?
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
, 2014 at 11:16 PM, Laurent Alebarde l.aleba...@free.fr wrote:
Thanks Pieter,
I assume that when the message comes here:
int zmq::stream_engine_t::write (const void *data_, size_t size_)
which executes:
ssize_t nbytes = send (s, data_, size_, 0);
the peer receives the same with the same
Then out_event / in_event are not used by inproc ?
Le 18/01/2014 08:18, Pieter Hintjens a écrit :
TCP is a stream transport, not a message transport. There's no way to
know how much data you will receive in any recv() call except to use
your own framing (which is why ZMTP has a framing
Le 18/01/2014 11:58, Goswin von Brederlow a écrit :
On Fri, Jan 17, 2014 at 11:40:13AM +0100, Laurent Alebarde wrote:
Hi Devs,
I am doing some experiments (cf at the end for the goal) and wonder
where I could hook the beginning of a message both reading and
writing.
What I want to do
Hi Devs,
I am doing some experiments (cf at the end for the goal) and wonder
where I could hook the beginning of a message both reading and writing.
What I want to do is prepend an outgoing message and trim an incoming
message (for any mechanism looks simpler) when some option is set.
=
write (outpos, outsize); , frame ? message ? several message possible ?
part of a frame possible ?
Le 17/01/2014 11:40, Laurent Alebarde a écrit :
Hi Devs,
I am doing some experiments (cf at the end for the goal) and wonder
where I could hook the beginning of a message both reading
https://github.com/zeromq/libzmq/blob/master/doc/zmq_bind.txt
https://github.com/zeromq/libzmq/blob/master/doc/zmq_ipc.txt
Le 17/01/2014 21:25, Srinivas Kotamarti a écrit :
Hi,
I had read the guide, from what I understand the inproc:// transport is for
inter thread communication. What I am
, Pieter Hintjens a écrit :
You can't add to a message without breaking ZMTP. What you could
conceivably do is inject command frames, and filter these out.
On Fri, Jan 17, 2014 at 2:57 PM, Laurent Alebarde l.aleba...@free.fr wrote:
For trimming an incoming message, the very beginning of in_event
That would be nice to have the RFCs inside libzmq git repository with a
status for each requirement if it is implemented or not. So when we
check out any version, we know easily what is in and what is not.
Le 15/01/2014 01:27, Victor Perron a écrit :
WHAT ! give me my money back ! :)
On
want to make additional documentation about what's implemented,
where, feel free to make it: we have a wiki exactly for that.
On Wed, Jan 15, 2014 at 10:25 AM, Laurent Alebarde l.aleba...@free.fr wrote:
That would be nice to have the RFCs inside libzmq git repository with a
status for each
Le 15/01/2014 12:27, Pieter Hintjens a écrit :
On Wed, Jan 15, 2014 at 11:55 AM, Laurent Alebarde l.aleba...@free.fr wrote:
My point is not to create a new document, but to :
1) put the RFC inside the libzmq repository
2) add flags to each requirement
The RFCs do not belong to libzmq
The function prototype is :
int zmq_setsockopt (void *socket, int option_name, const void
*option_value, size_t option_len);
So you can use anything. Inside options.cpp, it is typecasted to
unsigned char*, and the attribute it is copied to is: unsigned char
identity[256]
If you want to
Le 10/01/2014 07:10, Matt Connolly a écrit :
Dear list,
I’m looking at using the STREAM socket to interface with some plain old TCP
clients, however, there seems to be two things I’m missing:
1. How do I send a message to a client first? Once the client sends a message I
can get the
Thanks a lot Pieter (I missed your 23:44 message - sorry).
Le 09/01/2014 09:08, Pieter Hintjens a écrit :
On Thu, Jan 9, 2014 at 7:50 AM, Laurent Alebarde l.aleba...@free.fr wrote:
And a 4th one: have the security protocol (CURVE or PARANO) build on top of
libzmq or czmq. They would simply
Hi Devs,
I am prototyping a ZMQ_STREAM based proxy to manage to proxy CURVE. My
first prototype with one client and one worker works, but is not very
usefull. I have to pair clients and workers. My first idea was to pair
identity-ies attributed by the ZMQ_STREAM socket. But it cannot work as
or whatever else while keeping
the used mechanism in libzmq, in a context of concurrent connexion, I
will take it.
Cheers,
Laurent.
Le 08/01/2014 19:52, Pieter Hintjens a écrit :
On Wed, Jan 8, 2014 at 7:03 PM, Laurent Alebarde l.aleba...@free.fr wrote:
I have to pair clients and workers
to know when a
handcheck is passed.
Besides, when a new client arrives and all workers are already in a
handcheck phase, either it is rejected with a retry later, either it is
queued.
Your thoughts ?
Le 08/01/2014 22:38, Laurent Alebarde a écrit :
Hi Pieter,
Thanks for your answer.
Yes, your
/2014 23:08, Laurent Alebarde a écrit :
One idea, let's call it case 3:
A worker can be paired with many clients, but only one in the hancheck
phase. For any client which has passed the handcheck, the proxy
prepends a frame with its identity when forwarding to the worker. The
worker resends
:
On Tue, Dec 31, 2013 at 5:01 PM, Laurent Alebarde l.aleba...@free.fr wrote:
In StreamQ-Proxy, I test that in the handcheck, I have CURVE, then
READY. From RFC/26, I SHOULD test:
!memcmp(content + 1, READY, 5)
Instead, I have to use:
!memcmp(content + 3, READY, 5)
OK, RFC 26 assumes you have some
The existing apps do not use yet 0MQ heartbeating anyhow, so there is no
backward compatibility issue.
I support Matt point of view to keep libzmq homogeneous. I add that I
don't like specifications or performances degradations when it can be
avoided. There are standard usages that sustend
At first glance, you are mixing up in your mind multi-part messages that
can be managed with more, with the problem of the need of several
reads when you read a certain amount of bytes lesser than the message sent.
So you need an inner loop that reads until rc 0. The last read will
have rc =
Here it is:
https://github.com/lalebarde/streamq-proxy/commit/17ba132cc444a08e78fb9c6e78f1f2436953e4eb#commitcomment-4969395
Le 02/01/2014 15:09, Pieter Hintjens a écrit :
Can you get a dump of the whole handshake sent by libzmq? Thanks.
On Tue, Dec 31, 2013 at 5:01 PM, Laurent Alebarde
Hi Devs,
In *StreamQ-Proxy*, I test that in the handcheck, I have CURVE, then
READY. From RFC/26, I SHOULD test:
!memcmp(content + 1, READY, 5)
Instead, I have to use:
!memcmp(content + *3*, READY, 5)
to have it work.
Is it a misunderstanding of mine or a discrepency between the RFC and
/12/2013 17:13, Laurent Alebarde a écrit :
Hi all,
I am pleased to announce you that *StreamQ-Proxy* is born.
StreamQ-Proxy aims at providing a proxy capable of proxying complex
0MQ security mechanisms. Today, if you want to set-up a server secured
with the CURVE mechanism as a broker
Hold on, I am in progress.
Le 30/12/2013 12:03, Laurent Alebarde a écrit :
Hi all,
Sorry to come back with this, I am still blocked with my attempt to
proxy CURVE with ZMQ_STREAM. The problem is depicted here
(https://github.com/lalebarde/streamq-proxy) in the status
Good news: it works now.
TODO:
1.
Test multi-part messages.
2.
Test asynchronicity (send several messages before waiting for
responses).
3.
Extend to many clients workers.
Le 30/12/2013 13:03, Laurent Alebarde a écrit :
Hold on, I am in progress.
Le 30/12/2013 12:03
Hi Devs,
In *test_stream.cpp*, the ZMQ_SNDMORE flag is tested on receive with:
rc = zmq_msg_recv (identity, stream, 0);
assert (rc 0);
assert (zmq_msg_more (identity));
and is set with:
rc = zmq_msg_send (identity, stream, ZMQ_SNDMORE);
I note that *zmq_msg_recv* / *zmq_msg_send*
So I answer to myself: yes.
Le 30/12/2013 18:02, Laurent Alebarde a écrit :
Hi Devs,
In *test_stream.cpp*, the ZMQ_SNDMORE flag is tested on receive with:
rc = zmq_msg_recv (identity, stream, 0);
assert (rc 0);
assert (zmq_msg_more (identity));
and is set with:
rc = zmq_msg_send
Now it works with multipart messages and asynchronous messages.
TODO: Extend to many clients workers.
Le 30/12/2013 15:31, Laurent Alebarde a écrit :
Good news: it works now.
TODO:
1.
Test multi-part messages.
2.
Test asynchronicity (send several messages before waiting
1 - 100 of 268 matches
Mail list logo
