I'm pretty sure the security model for that deployment as far as libzmq is concerned is "I trust everything on the network segment". There's probably ways to deal with that at the application level, but if you're worried about eavesdropping you probably want to be using a different transport.
Roger, so my understanding of how it works is ok :)
thank you
thank you
Has someone experiences with JeroMQ and 'Connection Heartbeating'?
We already use application-level heartbeating but I was curious whether the following could help/simplify this. The README.md states that it follows the ZMTP/3.0 but heartbeating seems to be part of ZMTP/3.1. How much of this is already working in JeroMQ?
The spec defines only one 'ping-ttl' timeout which I guess is the one mapped to Socket::setHeartbeatTtl(int) (A). What is the difference w.r.t. 'Socket::setHeartbeatTimeout(int)' (B)? Is this an asymmetric time-out definition ala
- 'if you do not respond to my ping after A ms, I consider you offline' and
- 'you may consider me offline, if I haven't sent any messages/pings within B ms'
andSocket::setHeartbeatTtl(int)setting the frequency of the transparent pings that my client sends under the hood?
For example if I choose the following socket parameters:
socket.setHeartbeatTtl(1000);
socket.setHeartbeatTimeout(3000);
socket.setHeartbeatIvl(200);Does this imply, that my client sends pings every 200 ms, if the other client/server does not reply within 1000 ms my client socket closes, and if I haven't sent any (new) pings for 3000 ms the other client/server may (or is forced to) close the socket on it's side? Does this work for all tcp-based socket combinations?
Any clarification/confirmation would be much appreciated.
1 reply
If there are NetMq users here It would be nice with some help:
https://stackoverflow.com/questions/66660127/netmq-unhandled-exception-best-practices
https://stackoverflow.com/questions/66660127/netmq-unhandled-exception-best-practices
I tried to use a DEALER <=> ROUTER <proxy> DEALER <=> DEALER
it works if the client (dealer) start the communication to the router, reaching the worker (dealer).
but the inverse is not working
grabber, have you looked at the Majordomo protocol? It solves this pattern in what I think is an elegant way.
grabber, have you looked at the Majordomo protocol? It solves this pattern in what I think is an elegant way.
"This broker connects a set of clients to a set of workers who register particular "services". Client requests are then sent to workers according to their availability, and replies sent back to the original clients."
The issue is how to start the communication from the worker to the clients.
I have been trying to use a ROUTER-to-ROUTER as a broker to be able to start the communication from client-to-worker or worker-to-client, but after 1 week trying, going without ideas.
Is there any example showing a ROUTER-to-ROUTER with a poller working?
1 reply
Doesn't anyone else here think that the socket monitor API is a little insane compared to just returning an error code from the connect call? Now I have to create a new thread, then have to have new zmq channels to talk to the main or other threads to tell them their crap doesn't work... and I now have more channels to monitor for errors.
4 replies
hello guys, is there an implementation somewhere for the inital handshake of curvezmq described here: http://curvezmq.org/page:read-the-docs#toc5. I want the client to send its public key to server and vice versa. My programming language is rust as there is a binding to libzmq, but i believe it doesn't have anything for inital handshake (it does for encrypting tho). Thanks!
The exchange happens in the background as part of the implementation of the CURVE security method. The client has extremely simple handling: you set the single server key you expect as a peer, and a connection will simply not complete if any other server appears. On the server, though, you need to run a ZAP server that will receive the client's public key and can make auth decisions.
The trivial answer is that CurveZMQ inherits certain properties from the CurveCP protocol that it's based on, and CurveCP punts so completely on the key distribution problem that the very first message on the wire requires the client to have knowledge of the server's long-term public key to construct.
We can get into the weeds on the various tradeoffs that decision imposes on systems using CurveZMQ if you want, subject to our apparent timezone difference, but you do have to deal with the fact that it's the only built-in way to cryptographically secure a ZMQ connection. If that doesn't match your security model you'll have to compromise somehow.
Hi there! I want to build an app where customers can “get in line” in a specific line, say “Technical support Apple” to be connected to a video meeting with a technician in the pool of “Apple technicians”. Can I create something like this with ZeroMQ in NodeJS and connect it to a React Native app?
Hey guys, I have to implement inter process communication between a python and c# application. Right now I'm using plain udp to achieve this but this has some drawbacks. First one the unreliable nature of udp, eventho I haven't noticed any performance issues this doesn't look 'clean'. Second one being that udp has a max packet size and my messages can become bigger than that, adding a fragmentation layer to udp seems like reinventing the wheel (tcp yay). The reason I didn't use tcp is because tcp has no notion of packets and threats everything as a stream, meaning that I'll have to add additional code to reconstruct the stream of bytes into packets before processing them on both the c# and python side. The communication needs to be directional. I came across zeromq and it looks like this problem can be solved using 0mq. However, I'm not sure this is the appropriate way as it seems that this library can do way more than I need and the simple case I would like to achieve isn't even described in the docs. I cannot use req/rep since the communication needs to be asynchronous. Pair seems to be inappropriate because it was designed with inter thread communication in mind and does not do auto reconnects. In some stackoverflow thread it was mentioned that dealer/dealer would be the simplest and most appropriate way of achieving this. However, this looks like a 'hack' to me. Does anyone else have some thoughts on this and can point me to the right direction?
Disclaimer: I am not a guru/core-developer but merely user of ZeroMQ. While there are a myriad of different options, using ZeroMQ is generally one of the better choices because of its performance, multi-language support and because it takes care of many (some of the dangerous) corner cases (connect/disconnects, time-outs, heart-beating, encryption, ...). The ROUTER-DEALER combination with its simplicity and Majordomo Pattern with its extensibility are quite good also for production use. There are many multi-language examples in the zguide. In the end it very much depends on your actual use-case whether you need an asynchronous RPC, a publish-subscribe, or other type of application...
well my use case is just a 1<->1, bidirectional, async communication between a c# and python app. I also came across the router<->dealer combination, but as in the dealer<->dealer combination it looks like a 'hack'. However, if that's the cleanest solution with 0mq I guess I'll go with it. For reference, the stackoverflow thread I refered to before: https://stackoverflow.com/questions/24122018/what-zeromq-socket-type-to-use-for-inter-process-communication
just want to keep it as simple as possible, PAIR would be perfect if it had the autoreconnect and wasn't designed mainly for inter thread communication
If you expect an answer for some messages it is convient to establish two channels one to publish messages one to receive messages
I'll try dealer<->dealer then
@wartek69 re. overengineering, it can be a bit daunting but ZMQ is very well designed in the sense of "take it or leave it" features. Especially with good bindings.
Would it be possible to connect 2 networks when using Zyre? I'm trying to make an application that connects using wifi, however, there could be multiple wifi-routers, and ideally all connected devices should be able to communicate, even is one is in the range 192.168.1. and the other on 192.168.2. . Is there some way to make this work?
So, I guess the answer is "mostly no".
I guess you could do stuff with overlay networks, but that's not usually considered an application concern.
zmq has about half of the feature set needed for this, on systems with
socketpair. The system call creates a connected pair of sockets that provide the properties you want, which can be passed to a subprocess using typical methods--that is, inherited from a fork, or sent along another established Unix socket. zmq can make use of that kind of socket via the ZMQ_USE_FD socket option, but only when binding. There's currently no equivalent facility for the connecting peer.
I think I actually interpreted the man page wrong and gave you bad information; it's not even supposed to be used for a connected socket, but a bound socket that's had
listen called on it so incoming connections can go to the ZMQ protocol machinery. The mentioned use case is systemd socket-activated services, where the listening socket gets created by the service supervisor and the service itself is lazily created with the socket already set up the first time something connects.
So the actual answer is just "no". the management regrets the error
@wartek69 re. overengineering, it can be a bit daunting but ZMQ is very well designed in the sense of "take it or leave it" features. Especially with good bindings.
@detly sorry for the late response, not very active on here, just saw your @ :D. I've implemented it using dealer <-> dealer and it seems to work without any issues, some example code can be found here: https://github.com/wartek69/zeromq_dealer_client_server