- 05 Nov, 2016 1 commit
-
-
Luca Boccassi authored
Solution: ignore it on kFreeBSD, as it is not an error Thanks Steven Chamberlain <steven@pyro.eu.org> for the patch!
-
- 01 Oct, 2016 2 commits
-
-
Nick Guiffrida authored
-
Nick Guiffrida authored
-
- 01 Jun, 2016 1 commit
-
-
Yann Diorcet authored
-
- 14 May, 2016 1 commit
-
-
evoskuil authored
-
- 04 May, 2016 2 commits
-
-
Doron Somech authored
-
Doron Somech authored
-
- 03 May, 2016 1 commit
-
-
somdoron authored
-
- 21 Feb, 2016 3 commits
-
-
Luca Boccassi authored
Solution: initialize class variable in the same order as they are defined.
-
Luca Boccassi authored
Solution: fix it
-
Osiris authored
Solution: The Coverity Static Code Analyzer was used on libzmq code and found many issues with uninitialized member variables, some redefinition of variables hidding previous instances of same variable name and a couple of functions where return values were not checked, even though all other occurrences were checked (e.g. init_size() return).
-
- 18 Feb, 2016 2 commits
- 11 Feb, 2016 1 commit
-
-
Pieter Hintjens authored
It's unclear which we need and in the source code, conditional code treats tweetnacl as a subclass of libsodium, which is inaccurate. Solution: redesign the configure/cmake API for this: * tweetnacl is present by default and cannot be enabled * libsodium can be enabled using --with-libsodium, which replaces the built-in tweetnacl * CURVE encryption can be disabled entirely using --enable-curve=no The macros we define in platform.hpp are: ZMQ_HAVE_CURVE 1 // When CURVE is enabled HAVE_LIBSODIUM 1 // When we are using libsodium HAVE_TWEETNACL 1 // When we're using tweetnacl (default) As of this patch, the default build of libzmq always has CURVE security, and always uses tweetnacl.
-
- 09 Feb, 2016 1 commit
-
-
Pieter Hintjens authored
These options are confusing and redundant. Their names suggest they apply to the tcp:// transport, yet they are used for all stream protocols. The methods zmq::set_tcp_receive_buffer and zmq::set_tcp_send_buffer don't use these values at all, they use ZMQ_SNDBUF and ZMQ_RCVBUF. Solution: merge these new options into ZMQ_SNDBUF and ZMQ_RCVBUF. This means defaulting these two options to 8192, and removing the new options. We now have ZMQ_SNDBUF and ZMQ_RCVBUF being used both for TCP socket control, and for input/output buffering. Note: the default for SNDBUF and RCVBUF are otherwise 4096.
-
- 28 Jan, 2016 1 commit
-
-
Constantin Rack authored
Solution: update to 2016
-
- 30 Nov, 2015 1 commit
-
-
Chris authored
Only start the heartbeat timer when the underlying mechanism is ready to stop cipher streams from trying to encrypt a heartbeat before the handshake has completed. Addresses issue #1601.
-
- 18 Nov, 2015 1 commit
-
-
somdoron authored
-
- 08 Nov, 2015 1 commit
-
-
Jens Auer authored
-
- 08 Oct, 2015 1 commit
-
-
Jens Auer authored
-
- 21 Aug, 2015 1 commit
-
-
Joe Eli McIlvain authored
Solution: Move the macros to a private header.
-
- 16 Aug, 2015 1 commit
-
-
reza.ebrahimi authored
-
- 23 Jul, 2015 1 commit
-
-
KIU Shueng Chuan authored
-
- 26 Jun, 2015 1 commit
-
-
Jonathan Reams authored
Set the ZMQ_HEARTBEAT_TIMEOUT to default to the value of ZMQ_HEARTBEAT_IVL if it's not explicitly set. Change the units of ZMQ_HEARTBEAT_TTL to milliseconds in the API and round down to the nearest decisecond so that all the options are using the same units. Make the maximum heartbeat TTL match the spec (6553 seconds)
-
- 24 Jun, 2015 1 commit
-
-
Jonathan Reams authored
This commit adds ZMTP connection heartbeats described in http://rfc.zeromq.org/spec:37/ZMTP.
-
- 14 Jun, 2015 1 commit
-
-
Jens Auer authored
zero-copy msg_t::init cannot be used when the message exceeds either the buffer end or the last received byte. To detect this, the buffer is now resized to the numnber of received bytes.
-
- 02 Jun, 2015 1 commit
-
-
Pieter Hintjens authored
Of course people still "can" distributed the sources under the LGPLv3. However we provide COPYING.LESSER with additional grants. Solution: specify these grants in the header of each source file.
-
- 19 May, 2015 1 commit
-
-
Brian Knox authored
-
- 22 Apr, 2015 1 commit
-
-
evoskuil authored
-
- 19 Feb, 2015 2 commits
-
-
Thomas Rodgers authored
-
Thomas Rodgers authored
-
- 18 Feb, 2015 1 commit
-
-
Thomas Rodgers authored
-
- 27 Jan, 2015 1 commit
-
-
Thomas Rodgers authored
-
- 23 Jan, 2015 1 commit
-
-
Pieter Hintjens authored
Symptom is that ZMQ_STREAM sockets in 4.1.0 and 4.1.1 generate zero sized messages on each new connection, unlike 4.0.x which did not do this. Person who made this commit also changed test cases so that contract breakage did not show. Same person was later banned for persistently poor form in CZMQ contributions. Solution: enable connect notifications on ZMQ_STREAM sockets using a new ZMQ_STREAM_NOTIFY setting. By default, socket does not deliver notifications, and behaves as in 4.0.x. Fixes #1316
-
- 22 Jan, 2015 1 commit
-
-
Pieter Hintjens authored
Solution: update for 2015 Fixes #1320
-
- 16 Jan, 2015 3 commits
-
-
Thomas Rodgers authored
-
Thomas Rodgers authored
std::map::insert() has always had range based insertion, removed explicit loops.
-
Thomas Rodgers authored
Allows non-C/C++ based clients easy access to the peer's IP address via zmq_msg_gets(&msg, "Peer-Address") instead of zmq_msg_get(&msg, ZMQ_SRCFD) followed by calls to getpeername and getnameinfo
-
- 19 Dec, 2014 1 commit
-
-
Pieter Hintjens authored
E.g. when server is not configured, and client tries PLAIN security, there is no hint of why this does not work. Solution: add debugging output for this case. Note that the various debugging outputs for security failures should probably be sent to an inproc monitor of some kind.
-
- 03 Dec, 2014 1 commit
-
-
Min RK authored
checks mechanism != NULL, or NULL + non-empty zap_domain
-