i had to add --enable-draft on the shell script that builds libzmq for iOS. i think it would be a good thing to allow users of this script to toggle it if necessary.
what would be a proper way to implement it, that is compliant with the way zmq is built on other platforms ?
i'd like to make a PR with that
I'm not sure I understand the question. "--enable-drafts" argument to libzmq's configure is the appropriate way to build libzmq with support for the "draft" sockets.
here, for example, is how the pyzmq words it. https://pyzmq.readthedocs.io/en/latest/howto/draft.html
since Swift and iOS SDKs burry thread-management at a very low level, my issue is very likely to come up for other iOS projects. DRAFT APIs are handy there.
after a brief check of that script, I'd suggest one appropriate thing would be to add a "$CONFIGUREFLAGS" environment variable to the "configure" call so the user can provide the extra --enable-drafts or other options. And, I'd consider setting this new CONFIGUREFLAGS based on a command line argument to the script.
oops, matrix at my underscore. I meant CONFIGURE_FLAGS
hi spidydev. pulling won't cause "mute" state. for pushing you can use a poller and check if the POLLOUT is raised. basically, it checks if the internal buffers have hit the high-water mark (HWM) or not
I've not used it but there is a "non-blocking mode" mentioned in zmq_send man page which gives EAGAIN when the send would block, if I read things correctly
Hello,
I recently upgraded the zmq library from 4.3.2 to 4.3.4 and I have issues on the setsockopt function.
On 4.3.2m_commSocket.setsockopt(ZMQ_IDENTITY, ++socketNr);
On 4.3.4 the setsockopt becomesm_commSocket.set(zmq::sockopt::identity, ++socketNr);
The problem is that the new set() function takes a constant as second parameter.
Does anyone knows how to fix this or how to approach this?
the now depreciated setsockopt and the new set both take a templated const T& opt. unless the deprecated function changed signature maybe something else is wrong?
I assume you are using pyzmq. The context will be closed once there are on more references to it being held.
the context object will self close when it destructs which in Python happens when there are no more references to it being held.
No, there is no packet loss on the network because TCP is used. But messages will be lost if the queues in the sockets are allowed to reach their HWM.
message loss occurs first after the receiver queue fills and then the sender queue for that receiver fills. The next message passed to a send() will be dropped.
one can set the HWM to infinity and then message loss will occur once all RAM is exhausted (likely due to your job being killed)
actually there is a second, and common, mode of message "loss". It occurs by sending message too soon right before the initial connection is completed. This is called the "slow subscriber syndrome" and is discussed in the zeromq guide.
barring infinite RAM, if a receiver is slower than a sender eventually messages must be lost
this works fine.. but the problem is that my peers might be destroyed due to inactivity... when it comes back, and I create a new peer with the same identity it seems sender router can't send to the new peer
I've published an SO question with some code.. https://stackoverflow.com/questions/72302591/reconnect-zmq-router-socket-with-custom-identity
hello, is there a backup wiki somewhere? the main one at http://wiki.zeromq.org/ seems to be recovering from a hack
thomasjm, the wayback machine has some snapshots https://web.archive.org/web/20220311103626/http://wiki.zeromq.org/
I think the content is also on github
i looked on github under the zeromq org and didn't see it
i actually have a question i haven't been able to answer in the docs, hoping someone here can help. after you
zmq_bind a socket, are you obligated to zmq_unbind it? or is it sufficient to just call zmq_close?
I think you can skip the unbind. but I normally work in C++ or python which I guess might do that for me in some destructor
fwiw, the example in the zmq_socket man page has no unbind. it goes straight to zmq_close
that's what i figured, i saw that unbind was added to the API somewhat later. i guess unbind is only for when you want to unbind a socket without destroying it, and then bind it again?