Hi Bill,
Bill Torpey writes:
> - In practice, it’s possible to share PUB sockets using mutexes if you’re
> careful.
> - It is not possible to share SUB sockets, period. It may appear to work,
> but at some point you
> will crash. (This has to do with lack of synchronization between user
Bill Torpey writes:
> - In practice, it’s possible to share PUB sockets using mutexes if you’re
> careful.
How about PAIR? Can I let one end be used from multiple different
threads if I assure all such access is protected by a mutex?
I'll add this to my test but if there is some prior
Hi again,
Fyi, I'm convinced not to push my luck with the non-thread safe sockets.
Even with tbb::flow::graph inherent mutex (concurrency=1) I was able to
make my test segfault or lose messages by adding an N-to-1 socket
connection pattern.
For reference, my updated test is copied below.
Also,
Bill Torpey writes:
> Tried using PAIR sockets for IPC and ran into problems
> (https://github.com/WallStProg/zmqtests/tree/master/threads,
> https://github.com/zeromq/libzmq/issues/2759 ).
Indeed! (crossed email)
> Why not use one of the thread-safe sockets?
Yes, I will try them next.
That
Hi,
I want to use ZeroMQ sockets from nodes in a multi-threaded
tbb::flow::graph and I worry if doing so will violate the socket rules
on threading.
The test (copied below) creates and destroys any given socket (zsock_t)
in the main thread. The tbb::flow::graph is also constructed there.
When
Hi John,
On Fri, Feb 28, 2020 at 7:05 PM John Jefferies
wrote:
>
> If you are using CZMQ, you can use zmsg_encode() and zmsg_decode() to
> serialise multi-part messages when using them with CLIENT/SERVER.
> Everything else in existing examples can remain the same. Obviously a bit
> less
Kevin Sapper writes:
> IMO you did a good job describing the Majordomo landscape. I'm not
> aware that any MDP library is currently actively maintenaned. Please
> prove me wrong.
Okay, thanks.
Right now, I'm trying to gsl-freshen the package to add Python bindings.
If I can manage to not
Hi,
I'm trying to understand the Majordomo protocol landscape. I thought it
was simple but the more I looked, the more confused I get. Let me
summarize what I find and please say where I get anything wrong.
Ultimately, I'm trying to figure out how best to adopt the general
Majordomo pattern
Hi,
I wrote up a "tour" of cppzmq in order to drive me to learn more about
it.
https://brettviren.github.io/cppzmq-tour/
Maybe it's of use or interest to others.
Cheers,
-Brett.
signature.asc
Description: PGP signature
___
zeromq-dev mailing
Hi Kevin,
Kevin Sapper writes:
> wow fantastic tour :)
Thanks! And thanks also for the kind words from everyone else.
> I would love this to become part of the official cppzmq documentation. At
> least you should add
> a link in the cppzmq README ;)
Yes, I have been thinking of how to
Hi Matteo,
Matteo writes:
> One doubt remains: I am binding a node to an address that is not of
> the machine where the node is located.
From zmq_bind(3):
The zmq_bind() function binds the socket to a local endpoint and then
accepts incoming connections on that endpoint.
So, a "bind"
Hi Seyed,
Seyed Hossein Mortazavi writes:
> I'm running the server and the client over a network with latency (160ms
> round trip). I create the latency using tc on both the client and the
> server:
>
> tc qdisc del dev eth0 root
> tc class add dev eth0 parent 1: classid 1:155 htb rate
Hi Simon,
This apparently has nothing to do with majordomo protocol versions.
It would help if you show your code but based on the small hints, I
agree with Brian. Remove the "*" in front of "sock".
If the build failed to find cppzmq header files you'd see much different
errors.
-Brett.
Jasper Jaspers writes:
> I have a publisher that needs to send a message to multiple subscribers and
> wait for each of
> the subscribers to receive and process the message. Is there a recommended
> socket or
> combination of sockets that can be used to achieve this messaging behavior?
I
Jasper Jaspers writes:
> What if I want the publisher to broadcast the message using a
> multicast like transport. Some published messages can be quite large
> and would like to limit amount of traffic on the wire if possible.
I have no experience with it but PUB supports a transport called
Hi Julius,
Some input from an interested ZeroMQ user:
There are some 10 and 100 GbE latency and throughput results in the
wiki. They focus on REQ/REP (lat) and PUSH/PULL (thr). The benchmark
and plotting code is in libzmq/perf/. The "thr" uses PUSH/PULL and its
code might be a good basis for
Hi,
Johnny Depp writes:
> [...code...]
This code looks okay to me.
> My problem is this: When I use this code in two separate simple applications,
> the above code
> works. However, when I move the server into a larger application with
> multiple threads, it is
> starting to behave
Hi again,
Johnny Depp writes:
> Yes, the pull socket is in only one thread
Okay. Then I guess something else is going on.
> However, I switched to sending chunks of memory using zsock_brecv and
> zsock_bsend. And I am back to no reaction. At all.
Maybe no longer relevant but just one
Johnny Depp writes:
> One more question: would the version of curl library be the problem? I
> have a different requirement that asked for an updated libcurl library
> and I had the most recent version of it installed...
I don't know but I'd guess not.
I've never noticed any curl-related
Hi Johnny,
Johnny Depp writes:
> zstr_send(client, json_string);
This returns an int which -1 will indicate some kind of error.
zstr_send() wraps a lot of functionality so -1 can mean one of a few
things went wrong. In any case, checking and acting on it would be part
of guaranteeing
Johnny Depp writes:
> What is the meaning of 'HWM'?
"High water mark". ZeroMQ also calls this "reaching mute state". In
"man zmq_socket" you can see for each socket what the behavior is.
-Brett.
signature.asc
Description: PGP signature
___
I was going to reply similarly. Once a message is outside a socket,
it's out of ZeroMQ's hands and the responsibility of the application.
This aspect is somewhat fresh in my own learning. The core issue here
(in my mind) is that the broker (router) severs any direct communication
between
Hi Mike,
"Alexander, Michael" writes:
> I have been using zmq_bind(socket, “tcp://lo:*”) to bind to a random
> unused port. I can find examples using other languages to use
> random_port to limit the range of ports (e.g. only assign a port
> between 3 and 31000). Is there a way to do this
Hi Ziang,
When faced with similar patterns/needs in my own work I consider what
might be done at different points in the data flow from upstream to
downstream and what implications that might have. Here are my thought
processes applied to the case you describe:
Would all subscribers want the
Ziang Gao writes:
> In this case, are there any libraries or modules you can recommend
> that can create a queue right after connecting the port?
I use C++ so would probably use simply a std::deque or std::vector as a
queue.
Inside the main loop of some class servicing the SUB I'd do like this
Hi Stephen,
This is incredibly cool to see!
I've always thought Node-RED was ripe for this kind of use but alas my
own JS skills are too lacking to move strongly into this area.
I'm very curious if you have thoughts in a similar direction I have
contemplated:
When I first learned about
Hi Luca,
2c from one IRC user:
I'd follow the channel just about anywhere that's not discourse/slack.
IRC is preferred but I would and do visit ZeroMQ matrix channels.
The most important thing in my mind is to maximize cohesiveness of the
FS/OSS IRC community. I think OFTC would be a safe bet
Hi Francis,
In some past testing of my own I reproduced the results for 100 Gbps
shown in the wiki. If you have not found them:
http://wiki.zeromq.org/results:100gbe-tests-v432
There is also an older 10Gbps test in the wiki which may be more
directly applicable.
I got 20 Gbps throughput in
Francesco writes:
> So in first scenario the zmq background thread used only 12% of cpu to fill
> 914Mbps ; in second
> scenario it uses 97% to fill 700Mbps...
>
> how's that possible?
This is a pure guess: are you experiencing ZeroMQ's internal Nagle's
algorithm?
The guess applies if a) your
Francesco writes:
> Here's what I get varying the spin_loop duration:
Thanks for sharing it. It's cool to see the effect in action!
> Do you think the cpu load of zmq background thread would be caused by
> the much more frequent TCP ACKs coming from the SUB when the
> "batching" suddenly
On Thu, Oct 5, 2023 at 10:11 AM Luca Boccassi wrote:
>
> On Thu, 5 Oct 2023 at 14:14, Brett Viren wrote:
>
> > Perhaps such a list already exists and simply needs more prominent display?
>
> It was already shared, even on the ML, more than once:
>
> https://lists.zero
Hi Luca,
On Thu, Oct 5, 2023 at 4:09 AM Luca Boccassi wrote:
>
> Have you tried to stop complaining and instead use the time to do the actual
> work required? I hear it can do wonders
>
I understand the frustration I hear in this response.
One difficulty I see for community members to do the
Hi Francesco,
I agree a refresh of the online API docs would be good. I think the
zeromq.org website takes its content from:
https://github.com/zeromq/zeromq.org
A PR to that repo is likely the first step to get zeromq.org updated.
It would be extra good if the API docs for development and
On Fri, Oct 20, 2023 at 12:03 PM Francesco wrote:
>
> Maybe an even simpler solution is to activate the Github "Pages" support in
> libzmq.org and link it with a github action that just uses the Asciidoctor
> generator to convert all of doc/*.txt into static HTML.
>
> What do you think about
Francesco writes:
> Update: apparently the point a) is blocked by point b).
>
> In more details: the Asciidoc modern syntax to get a cross-reference
> correctly rendered in both manpages and HTMLs is:
>
> xref:name_of_doc.adoc[name_of_doc]
FWIW, I think it is very reasonable to accept some
Hi Joris,
Some time is needed for the PUB-SUB connection to be fully
established. This is imitated by our app code with bind()/connect()
calls but ultimately completed behind the scene by libzmq. The time it
takes depends on how long it takes the ends call bind() and connect()
and then some
On Thu, Dec 15, 2022 at 8:58 AM Brett Viren wrote:
> This is imitated by our app code with bind()/connect()
> calls but ultimately completed behind the scene by libzmq.
I mean *initiated* no imitated!
-B.
___
zeromq-dev mailing list
zero
Hi Francesco,
I implemented such an algorithm in C++ which I call "zipper".
The idea is simply to maintain a min-heap priority queue keyed on the
timestamp and surround that with policy logic to decide when to push
and pop based on examining the system clock. I've implemented two
policies.
?
> I'm asking because in my case the application is using just 1 single SUB that
> is connected with zmq_connect() to a number N of TCP endpoints. That makes
> the order of packets obtained from zmq_msg_recv() not time-ordered...
>
> Thanks!!
>
> Francesco
>
>
> Il
Hi Stéphane and everyone,
I find libzmq master always works when I use it. I have never had
problems developing against it.
But, that is not enough to overcome the "social problem" of infrequent
tagged releases.
For example, the version of libzmq distributed with Debian and
presumably other
What you describe is almost:
http://zguide.zeromq.org/page:all#Basic-Reliable-Queuing-Simple-Pirate-Pattern
The difference is you say you want clients to determine which backend
"worker" shall receive the task based on the client providing some
"name". To provide that, the "load balancer" in
Hi Doron,
It's very bold and modern looking.
Just my 2c feedback as a devoted user:
I think Mongrel2 should be listed under "Used by".
The corporate logos provide nothing useful to me. I can't learn
anything more about ZeroMQ knowing that there is a particular corporate
stamp on its main
Doron Somech writes:
> Can you make a pull request for the mongrel 2 logo?
I'll try tonight after $dayjob.
As-is, it will have color while the others are B:
https://en.wikipedia.org/wiki/File:Mongrel_2_logo.png
Do you have thoughts on that? I can have a go at making a silhouette to
match
Hi Arnaud,
Arnaud Loonstra writes:
> * visualising zmq topologies? In theory this should be very well
> possible. Would this be interesting for the zmq community? I'm currently
> researching a system to visualize actors but was thinking this could be
> done for any zmq topology. It is also a
Attila Magyari writes:
> Reading the docs all the other sockets seem to have extra restrictions or
> complications, which would not meet my needs:
> - bidirectional
I assume you mean symmetrically bidirectional?
If so, a pair of PUSH/PULL (or PUB/SUB) on each end would provide that.
> - no
Hi again, Attila,
Attila Magyari writes:
> So having two sockets, one for sending and one for receiving is the way to
> go?
Disclaimer: I'm a zeromq amateur so take my advice as such. I don't
know if this two-socket approach is best but it's certainly one way to
do it. (For a design that
Hi,
Arnaud Loonstra writes:
> The other way to analyse the problem is to check how EVASIVE is used at
> the moment... and maybe if it used at all. My experience is that since
> its introduction in a stable version, not once was is useful in
> real-world cases for me.`
Initially I thought
This is very useful information. Thank you for sharing it.
I have some 10 GbE hardware on order and hope to reproduce this myself
and answer these questions but I'm curious to know:
- The page shows PUB/SUB on inproc://, how does PUB/SUB perform on 10
GbE tcp://?
- How are dropped messages
Francesco writes:
> If you are referring the PUB/SUB proxy throughput graph, consider it's
> generated by
> this util
> https://github.com/zeromq/libzmq/blob/master/perf/proxy_thr.cpp
> which uses ZMQ_XPUB_NODROP=1 so there are no drops at all :)
Oh, wow! I didn't know this feature. This
SIMON BABY writes:
> I am looking for a sample source code in c++ with multiple end-points defined
> in the same process.
> Basically my process has to send a receive messages to/from other processes.
These two requirements seem contradictory to me.
In any case, the zmqpp package has tests
Hi Francesco,
I confirm your benchmark using two systems with the same 100 Gbps
Mellanox NICs but with an intervening Juniper QFX5200 switch (100 Gbps
ports).
To reach ~25 Gbps with the largest message sizes required "jumbo frame"
MTU. The default mtu=1500 allows only ~20 Gbps. I also tried
Doron Somech writes:
> You need to create multiple connections to enjoy the multiple io threads.
>
> So in the remote/local_thr connect to the same endpoint 100 times and
> create 10 io threads.
Fantastic!
10 threads in both remote_thr and local_thr,
10 connect() calls in remote_thr.
Hi Kevin,
Kevin Sapper writes:
> I think we need for zproto to be aware of zproject. Meaning if there's
> an api file for a class we should not generate and override the
> zproject headers.
>
> Maybe instead of generating header files zproto could generate api
> files. That way we avoid
Hi,
I'm rather confused about what should be generating headers and source
when both zproto and zproject are used.
Trying three ways:
1:
(rm all generated source and headers)
gsl project.xml
2:
(rm all generated source and headers)
gsl project.xml
make code
3:
(rm all generated
Hi Robert,
Bob Eby writes:
> Brett Viren wrote:
>> And, what I *really* need is the Majordomo pattern but with
>> CLIENT/SERVER for thread-safety.
>
> Pardon if I'm not quite following here, but isn't every ZeroMQ "message" an
> atomic operation already? I
Stepping back, I guess with cppzmq one need not ("should" not) drop down
to libzmq for polling.
Here's an example of using zmq::poller_t with a couple sockets. It may
not be properly idiomatic (please comment on better form), but maybe it
helps.
zmq::poller_t<> poller;
poller.add(pipe,
Hi Juergen,
Juergen Gnoss writes:
> if I run 2 instances of the program on the same machine, it does as
> (I) expect. if I run it on different machines it does strange things
> I do not understand at all.
Without looking carefully at your code/logs, I'd suspect that an OS or
network firewall
Hi John,
John Lång writes:
> the large messages are in the order of 12 megabytes
In my limited experience over LANs this is not so overly large to
warrant any special treatment.
> The small messages either contain payload data or the size of the next
> large message
ZeroMQ messages carry
John Lång writes:
> I just like to point out that I'm indeed interested in maximising
> throughput
Over what bandwidth?
Unless you are trying to fill > 20 Gbps, nothing particular special need
be done. Below that bandwidth, doing anything "special" will needlessly
(imo) complicate your code
Hi again,
John Lång writes:
> About HWM, do you think it would make sense assuming a HWM of 1 in the
> model? I think HWM 1 would be the worst case scenario where messages
> are most likely to be dropped. HWM 1 would mean that there can be only
> either one small or one large message in
John Lång writes:
> Thanks for your answer!
And, thanks to Bill Torpey's reply, I should clarify I only had TCP
transport in my mind.
> I should have mentioned that I'm approximating something like HWM 1
> because buffering would explode the state space of my model very
> badly. The model
Hi John,
John Lång writes:
> I'm reading this man page:
> https://linux.die.net/man/3/zmq_socket_monitor
> It seems to suggest that socket monitor is only available for pair
> type connections. Is that right? I'm using publish-subscribe.
I think that is a misunderstanding. A PAIR is used to
John Lång writes:
> If I'm using, say TCP, is 0MQ really able to guarantee zero-copy
> message transmission? (As an anecdote, somebody once told me that the
> 0 in 0MQ means zero-copy. I don't know if this is true or not.)
Zero:
https://zguide.zeromq.org/docs/preface/#The-Zen-of-Zero
John Lång writes:
> • When there is a message in transit between two processes and the sender
> attempts to transmit another message, then the new message will be dropped.
No. Or at least not necessarily. My mental picture is:
(sender app)-[sender socket]-[sender queue]
->-transport->-
Lei Jiang writes:
> Looks like I need to understand the MDP in better detail. I will give
> current design another try before exploring the MDP/PPP. My current
> plan is to "game" the router socket to route to the peer I want. For
> that I will maintain my own mappings. A list of all peer
Lei Jiang writes:
> Regarding the proxy() call marshalling should be light I totally agree.
> Though the project I'm working on
> is just hobby, in my job industry there are sometimes customers
> fussing about milli-second level delays.
Even over tcp://, ZeroMQ latency is measured in tenths of
"Axel R." writes:
> @Brett: You wrote:
>
> Not reliability per se but messages will not be recv()'ed in the order
> that they were send()'ed when zeromq is configured with more "I/O"
> threads than the default.
>
> This is a little concerning: how increasing the number of threads
Francesco writes:
> Any comment is welcome.
Just to say that this is really great work! Kudos to you and Luca.
-Brett.
signature.asc
Description: PGP signature
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
s/zeromq/ project.
> RTD allows to add as many maintainers as needed to a single "project"
> (like zeromq)... AFAICT all
> maintainers have same rights/permissions.
> I think it would be best to have all libzmq maintainers added there to
> ensure there will b
Lei Jiang writes:
> While putting together my code, I find it a bit hard to keep the
> implementation simple and efficient. For
> example, the routing IDs are separated by empty frames as delimiters.
> According to some charts in the guide,
> multiple IDs could be separated by multiple
Hi Francesco,
I think you should have no problem reclaiming the name "libzmq" on RTD.
I find this policy page:
https://docs.readthedocs.io/en/stable/abandoned-projects.html
Scroll down for the info to provide and the link for how to request a
change.
Cheers,
-Brett.
Francesco writes:
>
Francesco writes:
> In meanwhile perhaps some libzmq maintainer can simply register a new
> project named "zeromq" and then later on we can setup some kind of
> redirection rule
RTD provides a "custom domain" aka a "subdomain" namespace. I
believe this would allow
Hi Lei,
I think what you describe matches the majordomo pattern (MDP).
https://zguide.zeromq.org/docs/chapter4/#Service-Oriented-Reliable-Queuing-Majordomo-Pattern
In that description of MDP, the request from a client includes a
"service name". The broker uses that name to route the request to
Hi again,
Lei Jiang writes:
> The MDP pattern is very interesting but I can't use it in my case. I
> am aiming to share data and resources inside a process so can't go
> inter-process.
Like all ZeroMQ things, there is no need to choose the transport
mechanism when writing the code. You may
Hi Dave,
Zyre is a common peer communication pattern in the ZeroMQ world.
In Python there is Pyre:
https://github.com/zeromq/pyre
-Brett.
Dave via zeromq-dev writes:
> Hello!
> Can anyone suggest best implementation for intra processes msgs exchange?
> All workers must be able to
Hi again,
Perhaps copy-paste the example:
https://learning-0mq-with-pyzmq.readthedocs.io/en/latest/pyzmq/patterns/pubsub.html
and play with it to get some understanding of the socket lifetimes and
timing of the subscription phase.
You might start with that code and modify it to get closer
Hi Lei,
Lei Jiang writes:
> What I meant was, ZMQ seems to keep multipart message frames together. I
> wrote some test code, in the same
> thread, sending interleaving frames using 2 sockets like this.
>
> ZMQFrame("frame 1-1").Send(client1, ZMQ_SNDMORE);
> ZMQFrame("frame 2-1").Send(client2,
Hi Raúl,
I feel that your questions may imply a deeper misunderstanding than what
they ask directly so let me offer a few comments that hopefully gets to
the real problems. Feel free to ask more.
Of course the "while True" loop in the sender will send only identical
copies of the same message
78 matches
Mail list logo
