[zeromq-dev] ZMQ router-dealer set-up: can old socket identities be recycled? ("inproc")

Kah-Chan Low kahchanlow at yahoo.com
Mon Nov 12 17:50:52 CET 2012

Thanks Peter for your fast response!

> Is it possible you're using 2^32 DEALER sockets?
No, I have way less than 100 sockets in my application when the problem hit.  But then as I mentioned, I explicitly assigned the socket IDs myself.

> If you're reusing identities for some other reason, you need to
> explain in more detail how you assign identities.

Well, it wasn't intentional but I ended up recycling IDs of dead sockets.  This is what I did:

void classA::initialize()
  std::string id(boost::lexical_cast<std::string>(this));  // boost::lexical_cast converts "this" pointer into std::string (eg. 0x43204940 -> "0x43204940")
  // Use the string rendition of "this" pointer as the socket ID

   m_socket.setsockopt(ZMQ_IDENTITY, id.c_str(), id.length());  // m_socket is a zmq::socket_t object (ZMQ dealer) and a member of classA


If I delete a classA object and then immediately allocate a new classA object, chances are pretty high (at least on Linux) that I get back the same memory block that I had just deallocated.  As a result the ID of the new socket will be the same as the defunct socket.  My main question is: why did the ZMQ router that was connected to the dead and disconnected socket still remember the dead socket, such that it interfered with the operation of a newly connected socket with the same ID?
If this is indeed a feature, it follows that I can't recycle the IDs of dead sockets and my socket IDs will have to become longer and longer when my application runs for an extended period of time, as sockets continually get deleted and allocated.  Would I get a performance hit because of that?

 From: Pieter Hintjens <ph at imatix.com>
To: Kah-Chan Low <kahchanlow at yahoo.com>; ZeroMQ development list <zeromq-dev at lists.zeromq.org> 
Sent: Monday, November 12, 2012 8:53 AM
Subject: Re: [zeromq-dev] ZMQ router-dealer set-up: can old socket identities be recycled? ("inproc")
Hi Kah-Chan,

Is it possible you're using 2^32 DEALER sockets?

See how router chooses an automatic peer ID, in
random.cpp:generate_random() and in bool zmq::router_t::identify_peer
(pipe_t *pipe_).

If you are hitting the 32-bit limit, then try raising it to 64 bits,
then send us a pull request if that works.

If you're reusing identities for some other reason, you need to
explain in more detail how you assign identities.


On Mon, Nov 12, 2012 at 10:24 PM, Kah-Chan Low <kahchanlow at yahoo.com> wrote:
> I am using the router(server)--dealer(client) set-up in C++.  In my
> application, an existing dealer(client) connection may be disconnected from
> the router any time and the socket deallocated.  Similarly new dealers may
> be created and connect to the router at any time.  Each dealer is contained
> inside an object and I cast the object pointer into a string and set that as
> the dealer's identity.  During the course of execution new objects are
> continually created and old objects deleted.  As a result, it is possible to
> get a new object with the same object pointer value as one that has been
> recently deleted.  From time to time I would discover that messages sent by
> a dealer of a newly allocated object were getting lost; and this invariably
> happened when the new object has the same pointer value as an object that
> had been recently deallocated.  I then switched to a naming scheme that
> avoided recycling old socket identity names and the problem went away!  So
> it looks like the router has memory of identities of disconnected socket.
> Is this intended.  My application is supposed to run for months and that
> means I have to use increasing long strings to ensure identity uniqueness.
> Won't this have an impact on performance?
> BTW, I am using "inproc" protocol.
> Thanks!
> KC
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20121112/bd1d5d4d/attachment.htm>

More information about the zeromq-dev mailing list