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 <[email protected]>
To: Kah-Chan Low <[email protected]>; ZeroMQ development list
<[email protected]>
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.
-Pieter
On Mon, Nov 12, 2012 at 10:24 PM, Kah-Chan Low <[email protected]> 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
> [email protected]
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
