- 08 Aug, 2017 1 commit
-
-
Simon Giesecke authored
* Problem: missing test for status code 300, inadequate assertion for status code 500 Solution: add test, change assertion (currently test fails) * Problem: gcc compiler error deprecated conversion from string constant Solution: declare variable as const * Problem: in case of ZAP handler returning a status code other than 200, no appropriate event is emitted Solution: immediately emit event after receiving reply from ZAP handler * Problem: endpoint address is not included in zap-reply monitor event Solution: added functions to retrieve endpoint address in zmq::i_engine and zmq::session_base_t removed unused code block in zmq::stream_engine_t::next_handshake_command * Problem: wrong formatting Solution: fix formatting * Problem: test fails because of EPIPE Solution: add EPIPE/ECONNRESET/ECONNAGAIN handling for more test cases
-
- 04 Aug, 2017 1 commit
-
-
Simon Giesecke authored
Solution: Define them in zmq.h and use them (currently in DRAFT API)
-
- 03 Aug, 2017 1 commit
-
-
Simon Giesecke authored
* Fixing #2002 one way of doing it * Mechanisms can implement a new method `error_detail()` * This error detail have three values for the moment: no_detail (default), protocol, encryption. + generic enough to make sense for all mechanisms. - low granularity level on information. * Fixing #2002: implementation of the error details The ZMQ_EVENT_HANDSHAKE_FAILED event carries the error details as value. * Removed Microsoft extenstion for enum member access This was leading to compilation error under linux. * Adaptation of CURVE test cases * Monitoring event: changed API for detailed events Removed ZMQ_EVENT_HANDSHAKE_FAILED and replaced it by: - ZMQ_EVENT_HANDSHAKE_FAILED_NO_DETAIL, - ZMQ_EVENT_HANDSHAKE_FAILED_PROTOCOL, - ZMQ_EVENT_HANDSHAKE_FAILED_ENCRYPTION Adaptation of text case `security_curve` * Removed event value comparison This was introduced for the previous API model adaptation * Removed the prints in std output and added missing details `current_error_detail` was not set in every protocol error cases * Fixed initialization of current_error_detail * Fixed error in greeting test case The handshake failure due to mechanism mismatch in greeting is actually a protocol error. The error handling method consider it like so and send a protocol handshake failure monitoring event instead of no_detail. Fixed the test_security_curve expectation as well. * Upgraded tests of monitoring events The tests check the number of monitoring events received * Problem: does not build under Linux or without ZMQ_DRAFT_API Solution: - properly use ZMQ_DRAFT_API conditional compilation - use receive timeouts instead of Sleep * Problem: duplicate definition of variable 'timeout' Solution: merged definitions * Problem: inconsistent timing dependencies Solution: reduce timing dependency by using timeouts at more places * Problem: assertion failure under Linux due to unexpected monitor event Solution: output event type to aid debugging * Problem: erroneous assertion code * Problem: assertion failure with a garbage server key due to an extra third event Solution: changed assertion to expect three events (needs to be checked) * Problem: extra include directive to non-existent file Solution: removed include directive * Problem: assertion failure on appveyor for unknown reason Solution: improve debug output * Problem: no build with libsodium and draft api Solution: add build configurations with libsodium and draft api * Problem: assertion failure on CI Solution: change assertion to reflect actual behaviour on CI (at least temporarily) * Problem: error in condition in assertion code * Problem: assertion failure on CI Solution: generalize assertion to match behavior on CI * Problem: assertion failures on CI Solution: removed inconsistent assertion on no monitor events before flushing improved debuggability by converting function into macro * Problem: diverging test code for three analogous test cases with garbage key Solution: extract common code into function * Problem: does not build without ZMQ_BUILD_DRAFT_API Solution: introduce dummy variable * Attempt to remove workaround regarding ZMQ_EVENT_HANDSHAKE_FAILED_NO_DETAIL again * Problem: EAGAIN error after handshake complete if there is no more data in inbuffer Solution: Skip tcp_read attempt in that case * Problem: handshaking event emitted after handshaking failed Solution: use stream_engine_t::handshaking instead of mechanism_t::status() to determine whether still handshaking * Include error code in debug output * Improve debugging output: output flushed events * Split up ZMQ_EVENT_HANDSHAKE_FAILED_PROTOCOL into ZMQ_EVENT_HANDSHAKE_FAILED_ZMTP and ZMQ_EVENT_HANDSHAKE_FAILED_ZAP * Fixed compilation without ZMQ_BUILD_DRAFT_API * Renamed ZMQ_EVENT_HANDSHAKE_SUCCEED to ZMQ_EVENT_HANDSHAKE_SUCCEEDED for language consistency * Renamed ZMQ_EVENT_HANDSHAKE_SUCCEED to ZMQ_EVENT_HANDSHAKE_SUCCEEDED for language consistency * Renamed ZMQ_EVENT_HANDSHAKE_SUCCEED to ZMQ_EVENT_HANDSHAKE_SUCCEEDED for language consistency * Fixed assert_monitor_event (require event instead of allowing no event) Reverted erroneous change to handshaking condition Renamed test_wrong_key to test_garbage_key Generalized assumption in test_garbage_key to allow for ZMQ_EVENT_HANDSHAKE_FAILED_NO_DETAIL with error == EPIPE * Better isolate test cases from each other by providing a fresh context & server for each * Added diagnostic output * Changed assertion to reflect actual behavior on CI * Fixed formatting, observe maximum line length * Fixed formatting, observe maximum line length * Increase timeout to check if this fixes valgrind run * Close server with close_zero_linger * Increase timeout to check if this fixes valgrind run * Increase timeout to check if this fixes valgrind run * Generalize assertion to also work with valgrind * Fixed formatting * Add more diagnostic output * Generalize assertion to also work with valgrind
-
- 27 Mar, 2017 1 commit
-
-
Thomas Braun authored
Solution: Use the appropriate assertion macro.
-
- 04 Jan, 2017 1 commit
-
-
Luca Boccassi authored
Solution: setsockopt returns EINVAL if the connection was closed by the peer after the accept returned a valid socket. This is a valid network error and should not cause an assert. To handle this we have to extract the setsockopt from the stream engine, as there's no clean way to return an error from the constructor. Instead, try to set this option before creating the engine in the callers, and return immediately as if the accept had failed to avoid churn. Do the same for the connect calls by setting the option in open_socket, so that the option for that case is set even before connecting, so there's no possible race condition. Since this has to be done in 4 places (tcp/ipc listener, socks connecter and open_socket) add an utility function in ip.cpp. Fixes #1442
-
- 01 Jan, 2017 2 commits
-
-
Vincent Tellier authored
The mechanism is instanciated during the handshake itself, when and error happen before this, the error method shall work anyway. An error handling with a NULL mechanism means the handshake fail, so the handshake failure event is also raised in this case.
-
Vincent Tellier authored
- removed the previously added encryption_error, less changes less bug - handshake fail is now signaled when an error happen while the mechanism is still hanshaking
-
- 30 Dec, 2016 3 commits
-
-
Luca Boccassi authored
Solution: wrap the event triggering in the DRAFT ifdef as well as the defines. This ensures that the event are returned only if the library was built with DRAFTs enabled. Also update the test case to expect the new events since it uses the catch-all mask. Although the sequence of event is different and this might be considered as an API breakage, using the catch-all ZMQ_EVENT_ALL mask implies that, well, all events are monitored so it's normal that new ones will be added. Users that don't want this kind of behaviour to change can simply monitor only the event that they care about.
-
Vincent Tellier authored
- Moved new events in draft section + added to zmq_draft.h - Removed the remainning tabs - Reverted the hard error (back to soft error) in curve_server.cpp => The feature doesn't works anymore
-
Vincent Tellier authored
Added two new monitoring events: - ZMQ_EVENT_HANDSHAKE_SUCCEED is raised once the encryption handshake succeed - ZMQ_EVENT_HANDSHAKE_FAILED is raised when it failed Both events are raised on server and client side.
-
- 15 Dec, 2016 1 commit
-
-
laplaceyang authored
-
- 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
-