1. 18 Jul, 2019 1 commit
  2. 16 Jul, 2019 1 commit
  3. 11 Jun, 2019 1 commit
  4. 10 Jun, 2019 1 commit
  5. 24 Mar, 2019 1 commit
  6. 10 Feb, 2019 1 commit
  7. 02 Feb, 2019 1 commit
  8. 06 Nov, 2018 1 commit
  9. 05 Nov, 2018 2 commits
  10. 15 Aug, 2018 4 commits
  11. 23 Jun, 2018 1 commit
  12. 30 May, 2018 1 commit
  13. 27 May, 2018 1 commit
  14. 26 May, 2018 3 commits
  15. 10 Mar, 2018 1 commit
    • Manuel Segura's avatar
      Pull request to merge porting to WindRiver VxWorks 6.x (#2966) · 4726f726
      Manuel Segura authored
      * Problem: Still need to port over more files to VxWorks 6.x
      
      Solution: Port more files to VxWorks 6.x
      
      * Problem: Need to port over remaining files to VxWorks 6.x. Also remove POSIX thread dependency for VxWorks (because of priority inversion problem in POSIX mutexes with VxWorks 6.x processes)
      
      Solution: Port over remaining files to VxWorks 6.x. Also removed POSIX thread dependency for VxWorks
      
      * Problem: Needed to modify TCP, UDP, TIPC classes with #ifdefs to be compatible with VxWorks 6.x.
      
      Solution:  Modify TCP, UDP, TIPC classes with #ifdefs to be compatible with VxWorks 6.x
      4726f726
  16. 02 Feb, 2018 1 commit
  17. 19 Sep, 2017 2 commits
    • sigiesec's avatar
      Problem: term "identity" is confusing · 9e7507b3
      sigiesec authored
      Solution: replace by "routing id"
      9e7507b3
    • Luca Boccassi's avatar
      Problem: zmq_connect fails after disconnect due to RECONNECT_IVL == -1 · edb4ca10
      Luca Boccassi authored
      Solution: when a connection breaks and ZMQ_RECONNECT_IVL is set to -1,
      which means a reconnection will not be attempted, send a message from
      the I/O thread to the application thread to make the socket call
      term_endpoint, which is the equivalent of manually calling
      zmq_disconnect.
      This way subsequent zmq_connect call to the same endpoint will attempt
      again to do a connection.
      Otherwise, for some socket types like SUBs, those new connects will
      fail as the endpoint is recorded, despite the connection having been
      permanently closed.
      
      Add test cases to exercise this corner case with TCP and IPC.
      edb4ca10
  18. 18 Sep, 2017 1 commit
  19. 07 Sep, 2017 1 commit
  20. 06 Sep, 2017 1 commit
  21. 04 Sep, 2017 1 commit
  22. 01 Sep, 2017 2 commits
  23. 08 Aug, 2017 1 commit
    • Simon Giesecke's avatar
      Problem: ZAP status codes != 200 do not result in an appropriate monitor event (#2665) · a6cef4ef
      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
      a6cef4ef
  24. 01 Jul, 2017 1 commit
    • Luca Boccassi's avatar
      Problem: CURVE server (connect) fails when client rebinds · d04065b7
      Luca Boccassi authored
      Solution: if a CURVE server is using zmq_connect, the same session
      will be used for any client "reconnect" (actual binds). This is
      acceptable, so do not assert if zap_pipe already exists during the
      handshake, but simply reuse it.
      Fixes #2608
      d04065b7
  25. 13 Jun, 2017 1 commit
  26. 12 Jun, 2017 1 commit
  27. 02 Jun, 2017 1 commit
    • laplaceyang's avatar
      fix bug: coredump if set linger and immediate together · 67a6594f
      laplaceyang authored
      In function session_base_t::reconnect, if we set immediate to 1 and set linger, we will get into first block of reconnect function, and set pipe to NULL, but we forget to cancel timer of linger. Once timer tiggered, we will get coredump. Solution: cancel timer in the end of set pipe to NULL
      67a6594f
  28. 29 Mar, 2017 2 commits
  29. 01 Jan, 2017 1 commit
    • Vincent Tellier's avatar
      Fixed issue #2227 second part · ffb31dca
      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
      ffb31dca
  30. 30 Dec, 2016 1 commit
    • Vincent Tellier's avatar
      Fixed issue #2227 · b6e9e0c2
      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.
      b6e9e0c2
  31. 15 May, 2016 1 commit