Chances are that you dont need to explicitly assign the socket IDs yourself.
If this is some sort of actor model implementation, I would say to have one socket per thread, and many actors/objects per thread. 2012/11/12 Kah-Chan Low <[email protected]> > 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 > > -- Sincerely yours, Apostolis Xekoukoulotakis
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
