Dear all,
I am new to zeromq. I have some questions about message queuing
broker (msgqueue.c) which use zmq_proxy() forward msgs between frontend and
backend.
In my testing code, the mobile client is using ZMQ_DEALER
socket to connect to this broker. But after some time, I
Can the mechanism of load balancing broker be changed so that exactly the
same send/recv pattern is followed regardless of which side connects?
On Thu, Jan 8, 2015 at 5:57 PM, Pieter Hintjens p...@imatix.com wrote:
In the lbbroker example all traffic flows through the broker.
On Thu, Jan 8,
Hi * !
I recently switched from ZMQ2 (pretty old) to ZMQ 4 and
since then have some problems in debugging with EINTR.
Following code:
do {
rc = zmsg_send (zrep, clsocket_);
if (rc0) {
if (errno ==
EINTR || errno == EAGAIN) {
logWarn(temporary failure in zmq send()
... will be tried
Suppose the identity string is only two bytes long, I pad with
zeros to get a string of eight bytes. What should the value of
option_len be, 2 or 8?
--
Peter Kleiweg
http://pkleiweg.home.xs4all.nl/
___
zeromq-dev mailing list
This is an oddball API choice (and there is a bug in the implementation),
in that option_value* is being used as both and input and an output
parameter.
The size you pass in must be be *at least* sizeof(fd_t) bytes, because it
will overwrite the supplied identity string with the resulting file
yes.
using blob_t = std::basic_stringunsigned char;
char buf[8] = { 'f', 'o', 'o', 0, 0, 0, 0, 0 };
blob_t a(foo);
blob_t b(buf, 8);
assert(a == b); // fails
I think there is another issue with all of this. By default (IIRC) the
identity is 5 bytes, so on a 64 bit platform, the passed in
Good question. They are made redundant by authentication via the ZAP
protocol. However they're not removed as apps may be using them. Thus,
they are deprecated. They should not be mentioned in the NEWS.
On Thu, Jan 8, 2015 at 3:40 PM, Peter Kleiweg pklei...@xs4all.nl wrote:
ZeroMQ introduces
ZeroMQ introduces three new options for setsockopt:
ZMQ_IPC_FILTER_PID
ZMQ_IPC_FILTER_UID
ZMQ_IPC_FILTER_GID
In the docs, it says these options are deprecated.
Why introduce options that are deprecated at the same time?
--
Peter Kleiweg
http://pkleiweg.home.xs4all.nl/
Thomas Rodgers schreef op de 8e dag van de louwmaand van het jaar 2015:
This is an oddball API choice (and there is a bug in the implementation),
in that option_value* is being used as both and input and an output
parameter.
The size you pass in must be be *at least* sizeof(fd_t) bytes,
Sorry to keep flogging this particular horse, but in re-reading the docs
for this option as I'm trying to clean it up...
NB: _option_value_ must be always big enough to hold sizeof(fd_t) bytes
no matter how small the identity length is.
There are few issues here -
Prior to commit 45c681
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
Does the broker demonstrated in the manual under:
http://zguide.zeromq.org/page:all#A-Load-Balancing-Message-Broker
demonstrate that
A) when each end makes a connection request, after they link up from the
broker, their messages route directly between one another
In this scenario, the messages
12 matches
Mail list logo
