On Thu, Sep 25, 2014 at 4:22 AM, Goswin von Brederlow goswin-...@web.de wrote:
Well, and a third time now. Both the now blocks and changed monitor
events are API changes that breaks existing stuff. One could even say
the ABI hasn't changed, only the API.
The changes to the monitor API broke
Not sure if someone has noticed that but I for this message when I create a
SUB/PUB broker
==6536== Invalid write of size 4
==6536==at 0x4135C6B: zmq::pipe_t::set_hwms(int, int) (pipe.cpp:483)
==6536==by 0x411FED4:
zmq::ctx_t::connect_inproc_sockets(zmq::socket_base_t*, zmq::options_t,
A quick question for the zeromq experts if I may?
Given a DEALER to ROUTER zeromq connection which is able to operate
asynchronously; what is the best way to coordinate inbound and outbound
message handling such that the DEALER socket is not blocked and an
application is able to react and send
Thank you for your replies so far. I'll clarify if it does matter that
I'm using Windows and libzmq 4.0.4.
W dniu 2014-09-25 04:38, Goswin von Brederlow pisze:
the ØMQ library
shall signal any pending events on the socket in an edge-triggered
fashion by making the file descriptor
You should at least use the standard valgrind suppression file that's
included in most ZeroMQ C/C++ projects.
{
socketcall_sendto
Memcheck:Param
socketcall.sendto(msg)
fun:send
...
}
{
socketcall_sendto
Memcheck:Param
socketcall.send(msg)
fun:send
...
}
Then, if
Please read the Guide and work through the examples, it has lots of
explanation and examples of how to do this kind of thing.
On Thu, Sep 25, 2014 at 10:36 AM, Riskybiz riskybizl...@live.com wrote:
A quick question for the zeromq experts if I may?
Given a DEALER to ROUTER zeromq connection
On Thu, Sep 25, 2014 at 09:00:28AM +0200, Pieter Hintjens wrote:
On Thu, Sep 25, 2014 at 4:22 AM, Goswin von Brederlow goswin-...@web.de
wrote:
Well, and a third time now. Both the now blocks and changed monitor
events are API changes that breaks existing stuff. One could even say
the
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
Hi all,
This is to announce a ZeroMQ hackathon in Brussels on 30 and 31 October.
This is the first of a series of classes, each has the goal of
building a new distributed system, as an excuse for learning to work
together with RFCs, GitHub pull requests, and of course ZeroMQ.
This particular
On Thu, Sep 25, 2014 at 11:09:15AM +0200, Dorvin wrote:
Thank you for your replies so far. I'll clarify if it does matter that
I'm using Windows and libzmq 4.0.4.
W dniu 2014-09-25 04:38, Goswin von Brederlow pisze:
the ØMQ library
shall signal any pending events on the socket in an
On Thu, Sep 25, 2014 at 01:49:13PM +0200, Arnaud Kapp wrote:
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,
On Thu, Sep 25, 2014 at 1:39 PM, Goswin von Brederlow goswin-...@web.de wrote:
That is fine for major changes where a completly new function makes
sense. But not for minor behaviour changes that only conern corner
cases. It doesn't make sense to end up with 20 zmq_sock() like
functions that
Dear Pieter,
As a figurehead of the zeromq project I think you should know that the
zguide and its examples, whilst a worthy effort, is actually a barrier to
the progress of a learner. As a newcomer to networking my interactions and
attempts to learn and use zeromq over the past year has been an
Thanks for your answer, and I'm so glad you didn't give up yet.
The irony of working on Windows is that while it's touted as a
platform for less competent developers, it is in fact much harder to
use than Linux, for ordinary development.
So my first recommendation to you, if you're not up to
Dear Riskybiz,
I posted several days ago, by recommendation of Pieter, a post about
building your first C++ examples with ZeroMQ in windows (and Ubuntu/Mac),
with the C++ ZMQCPP binding and using the biicode platform. In this way,
even my students at university are able to build the examples in a
On Wed, Sep 24, 2014 at 7:45 PM, Goswin von Brederlow goswin-...@web.de
wrote:
As a side note: The monitoring interface exposes the IP address. You
can use that to monitor who connects (for logging purposes).
Well that's useful to know!
To be clear, we aren't interested in using IP for
Sigh, no good deed goes unpunished...
To your original question -
As covered in the zguide, ZeroMQ is already managing a background thread on
your behalf that is 'pumping' the underlying transport's socket and pulling
messages/sending messages as fast as it can (using epoll, select, IOCP,
etc.
Complaints are not the only (or best) measure of quality.
How many questions does the multitude of semi-redundant functions generate on
this list,
especially from new users trying to get started? (More so, since some functions
take void*
and so can't validate by argument type).
Perhaps it's
The surface API remains simple enough, as we deprecate older calls and
remove them from examples and so on. The man pages are quite explicit
about marking deprecated API calls.
We can be more brutal about removing deprecated code, though I've not
seen anyone raise an issue with the current
Speaking as someone who started with zeromq at version 2: The breaking
changes between 2 and 3 almost caused me to abandon zeromq altogether.
Since 3.2 (if I'm remembering correctly that 3.2 was the fix this mess
version), things have been relatively smooth sailing.
I've been routinely
A while back I ran into this same issue; my solution was to have the client
transmit an identifier (in my case, the public IP) when it first connects.
Annoying that this isn't possible (to my knowledge) using only ZMQ APIs,
but not the end of the world.
-E
On Thu, Sep 25, 2014 at 7:46 AM, Scott
Your code could be stripped down a lot:
1) PUB socket is only for sending. There's no need to test it for
ZMQ_POLLIN.
2) PUB socket never blocks when sending. There's no need to test it for
ZMQ_POLLOUT.
3) SUB socket is only for receiving. There's no need to test it for
ZMQ_POLLOUT.
4) The ZMQ_FDs
On Thu, Sep 25, 2014 at 02:08:41PM +0100, Riskybiz wrote:
Dear Pieter,
As a figurehead of the zeromq project I think you should know that the
Maybe you ment spokesperson or prominent programmers instead of
figurehead? I assume you didn't ment Pieter is just a puppet.
zguide and its
Hi Pieter-
The kernel is in a fairly unique situation: you can only have one installed at
a time.
(Yes, I know there was some effort to make ZMQ a kernel module.)
For libraries, you can have many different major versions installed at a time,
and executables can explicitly link against the one
On Thu, Sep 25, 2014 at 02:20:07PM +0200, Pieter Hintjens wrote:
On Thu, Sep 25, 2014 at 1:39 PM, Goswin von Brederlow goswin-...@web.de
wrote:
That is fine for major changes where a completly new function makes
sense. But not for minor behaviour changes that only conern corner
cases.
25 matches
Mail list logo
