Zeromq isn't saving anything to persistent storage. So let's say you have program A and program B. You set explicit identities on all sockets that both programs use and then connect them together. Now, let's assume you are sending data back and forth between A and B but you decide to shutdown program A for some period of time. When you restart program A and it reconnects to B with the same identity as before, program B will send any messages to A that were still in queue. As far as program B is concerned, program A just went away for a little while.
Nothing was persisted to disk; this data was still in memory inside of program B. Make sense? cr On Nov 12, 2012, at 2:45 PM, Kah-Chan Low <[email protected]> wrote: > Strictly speaking I don't have to explicitly assign socket IDs. I thought it > would make debugging easier because I have multiple sockets (one for > receiving and another for sending messages, for instance) per object and it > would be easier to identify sockets belonging to the same object by giving > them names having the same pre-/post-fix. > > Meanwhile I re-read the man page for ZMQ_IDENTITY and the following is now > making more sense: > The ZMQ_IDENTITY option shall set the identity of the specified socket. > Socket identity determines if existing ØMQ infrastructure (message queues, > forwarding devices) shall be identified with a specific application and > persist across multiple runs of the application. > If the socket has no identity, each run of an application is completely > separate from other runs. However, with identity set the socket shall re-use > any existing ØMQ infrastructure configured by the previous run(s). Thus the > application may receive messages that were sent in the meantime, message > queue limits shall be shared with previous run(s) and so on. > > > Still, the passage above is kind of misleading in the sense that it seems to > suggest setting the ID of a socket enables 0MQ to store information across > different invocation of the same program (as in typing the command at the > UNIX prompt). How is it possible for 0MQ to remember anything in a previous > invocation of a program? All this info will have been to saved in a file > right? I don't see any 0MQ-related file created on my file system. > > What does the passage above actually mean? Does it simply mean what I have > observed, that sockets connected to sockets with explicitly assigned IDs will > remember something about the latter even after the latter have been later > disconnected and destructed? > > From: Apostolis Xekoukoulotakis <[email protected]> > To: Kah-Chan Low <[email protected]>; ZeroMQ development list > <[email protected]> > Sent: Monday, November 12, 2012 12:12 PM > Subject: Re: [zeromq-dev] ZMQ router-dealer set-up: can old socket identities > be recycled? ("inproc") > > 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
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
