1. 14 May, 2016 1 commit
  2. 18 Feb, 2016 1 commit
  3. 29 Jan, 2016 1 commit
  4. 28 Jan, 2016 1 commit
  5. 20 Dec, 2015 1 commit
  6. 06 Sep, 2015 1 commit
  7. 28 Jul, 2015 1 commit
    • Brian Silverman's avatar
      Fix a documented memory leak. · 97969808
      Brian Silverman authored
      Despite the old comments, re-initing the msg_t leaks a refcount to
      metadata in some situations.
      
      v1_decoder looks like it isn't tested any more, but it seems like a good
      idea to fix it because it has the exact same piece of buggy code
      v2_decoder does.
      97969808
  8. 22 Jul, 2015 1 commit
  9. 05 Jul, 2015 1 commit
    • Jens Auer's avatar
      "zero-copy" raw_decoder · 36797936
      Jens Auer authored
      A memcpy is eliminated when receiving data on a ZMQ_STREAM socket. Instead
      of receiving into a static buffer and then copying the data into the
      buffer malloced in msg_t::init_size, the raw_decoder allocates the memory
      for together with the reference-counter and creates a msg_t object
      on top of that memory. This saves the memcpy operation.
      
      For small messages, data is still copied and the receive buffer is reused.
      36797936
  10. 14 Jun, 2015 3 commits
    • Jens Auer's avatar
      Reuse buffer when no messages depend on it. · e70b5efa
      Jens Auer authored
      e70b5efa
    • Jens Auer's avatar
      Fixed wrong handling of shared messages · 51cb57e2
      Jens Auer authored
      The shared reference count was not shared but copied. msg_t cannot
      store the refcnt itsef but has to store a pointer to an externally
      allocated (shared) refcnter. The changes to lmsg are reverted to
      use content_t again. Howver, this introduces an allocation in v2_decoder
      when creating the message which can be avoided. When allocating the reception
      buffer, space is allocated for the maximum number of reference counts
      (8192 / max_vsm_size = 8192/64 = 128 zmq:atomic_counter objects). This
      increases the buffer by 128*sizeof(atomic_counter) = 128*4 = 512 bytes only.
      When creating a message, the refcnt member is set to the address of one of the
      pre-allocated atomic_counter_t objects. To do so, a new msg_t type zcmsg
      is introduced because msg::copy must discriminate between the message types
      when releasing memory.
      51cb57e2
    • Jens Auer's avatar
      Fixed wrong buffer end detection in v2_decoder. · dfe19080
      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.
      dfe19080
  11. 03 Jun, 2015 1 commit
    • Jens Auer's avatar
      zero-copy message receive · e9b403a7
      Jens Auer authored
      Construct messages from a reference-counted buffer allocated once
      per receive instead of copying the data.
      e9b403a7
  12. 02 Jun, 2015 1 commit
  13. 22 Jan, 2015 1 commit
  14. 02 Jan, 2014 1 commit
  15. 04 Sep, 2013 1 commit
    • Pieter Hintjens's avatar
      Updated libzmq to match RFC 23, 24, 25, 26 · 28b0a5fa
      Pieter Hintjens authored
      * Command names changed from null terminated to length-specified
      * Command frames use the correct flag (bit 2)
      * test_stream acts as test case for command frames
      * Some code cleanups
      28b0a5fa
  16. 11 Apr, 2013 1 commit
  17. 12 Mar, 2013 2 commits
    • Pieter Hintjens's avatar
      785ef41f
    • Pieter Hintjens's avatar
      Removed corporate advertisements from source file headers · f0f16505
      Pieter Hintjens authored
      Copyrights had become ads for Sustrik's corporate sponsors, going against the original
      agreement to share copyrights with the community (that agreement was: one line stating
      iMatix copyright + one reference to AUTHORS file). The proliferation of corporate ads
      is also unfair to the many individual authors. I've removed ALL corporate title from
      the source files so the copyright statements can now be centralized in AUTHORS and
      source files can be properly updated on an annual basis.
      f0f16505
  18. 13 Nov, 2012 1 commit
  19. 05 Sep, 2012 1 commit
    • Martin Hurton's avatar
      Implement new message encoder/decoder · 3f6148ab
      Martin Hurton authored
      This is supposed to become part of the ZMTP/1.1.
      
      The main differences from the ZMTP/1.0 framing protocol are:
      - flags field comes first, followed by the length field
      - long messages are signaled using a flag rather then 0xff escape
      - length field does not include the flags field, 0 is a valid value
      3f6148ab