1. 27 Jun, 2019 2 commits
  2. 10 Jun, 2019 1 commit
  3. 18 May, 2019 1 commit
  4. 17 May, 2019 1 commit
  5. 12 Apr, 2019 1 commit
    • Luca Boccassi's avatar
      Problem: man errors, can't break lines · 8f77150c
      Luca Boccassi authored
      Solution: add space between OR'ed values
      
      zmq_getsockopt.3 2472: warning [p 17, 9.5i, div '3tbd1,1', 0.5i]: can't break line
      zmq_setsockopt.3 3471: warning [p 24, 1.8i, div '3tbd1,1', 0.5i]: can't break line
      8f77150c
  6. 14 Dec, 2018 1 commit
  7. 13 Sep, 2018 1 commit
  8. 15 Aug, 2018 1 commit
  9. 26 Jun, 2018 1 commit
  10. 25 May, 2018 1 commit
  11. 14 May, 2018 1 commit
  12. 10 May, 2018 1 commit
  13. 28 Apr, 2018 1 commit
  14. 23 Mar, 2018 2 commits
  15. 21 Mar, 2018 1 commit
  16. 15 Mar, 2018 1 commit
  17. 02 Mar, 2018 1 commit
  18. 23 Nov, 2017 1 commit
  19. 09 Oct, 2017 1 commit
  20. 19 Sep, 2017 3 commits
  21. 07 Sep, 2017 3 commits
  22. 20 Aug, 2017 1 commit
  23. 31 Jul, 2017 1 commit
    • Brian Russell's avatar
      Add socket option BINDTODEVICE · b963542e
      Brian Russell authored
      Linux now supports Virtual Routing and Forwarding (VRF) as per:
      
      https://www.kernel.org/doc/Documentation/networking/vrf.txt
      
      In order for an application to bind or connect to a socket with an
      address in a VRF, they need to first bind the socket to the VRF device:
      
          setsockopt(sd, SOL_SOCKET, SO_BINDTODEVICE, dev, strlen(dev)+1);
      
      Note "dev" is the VRF device, eg. VRF "blue", rather than an interface
      enslaved to the VRF.
      
      Add a new socket option, ZMQ_BINDTODEVICE, to bind a socket to a device.
      In general, if a socket is bound to a device, eg. an interface, only
      packets received from that particular device are processed by the socket.
      
      If device is a VRF device, then subsequent binds/connects to that socket
      use addresses in the VRF routing table.
      b963542e
  24. 14 Jul, 2017 1 commit
    • Marc Sune's avatar
      Problem: adapt, clarify docs ZMQ_ROUTER_MANDATORY · 609c1312
      Marc Sune authored
      Solution:
      
      * Document the new behaviour when generating 'ZMQ_POLLOUT' events
        for ZMQ_ROUTER sockets with 'ZMQ_ROUTER_MANDATORY' set to `1`
      * Add clarifications for 'ZMQ_ROUTER' socket when
        'ZMQ_ROUTER_MANDATORY' is set to `1`
      609c1312
  25. 24 Apr, 2017 1 commit
  26. 03 Jan, 2017 1 commit
  27. 26 Dec, 2016 2 commits
  28. 16 Nov, 2016 1 commit
  29. 03 Jun, 2016 1 commit
  30. 01 May, 2016 1 commit
    • hitstergtd's avatar
      Problem: zmq_setsockopt(3) man page formatting · 4809926c
      hitstergtd authored
      Solution:
      - Update formatting and remove redundant parts from ZMQ_PROBE_ROUTER,
      ZMQ_USE_FD, ZMQ_TCP_MAXRT, ZMQ_TCP_TOS
      - Only cosmetic changes to the content
      - These changes already merged on api.zeromq.org by me
      4809926c
  31. 20 Mar, 2016 1 commit
    • Frederic Tregon's avatar
      Fixed issue #1695 (ZMQ_REQ_CORRELATE) · e45dfe3b
      Frederic Tregon authored
      Problem: when using ZMQ_REQ_RELAXED + ZMQ_REQ_CORRELATE and two 'send' are
      executed in a row and no server is available at the time of the sends,
      then the internal request_id used to identify messages gets corrupted and
      the two messages end up with the same request_id. The correlation no
      longer works in that case and you may end up with the wrong message.
      
      Solution: make a copy of the request_id instance member before sending it
      down the pipe.
      e45dfe3b
  32. 09 Feb, 2016 2 commits
    • Pieter Hintjens's avatar
      Problem: ZMQ_TCP_RECV_BUFFER/SEND_BUFFER are redundant · 7470c00d
      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.
      7470c00d
    • Pieter Hintjens's avatar
      Problem: ZMQ_XPUB_VERBOSE_UNSUBSCRIBE is clumsy · 7f6ed167
      Pieter Hintjens authored
      This option has a few issues. The name is long and clumsy. The
      functonality is not smooth: one must set both this and
      ZMQ_XPUB_VERBOSE at the same time, or things will break mysteriously.
      
      Solution: rename to ZMQ_XPUB_VERBOSER and make an atomic option.
      
      That is, implicitly does ZMQ_XPUB_VERBOSE.
      7f6ed167