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

[Kah-Chan Low]

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 <xekoukou at gmail.com>
To: Kah-Chan Low <kahchanlow at yahoo.com>; ZeroMQ development list <zeromq-dev at lists.zeromq.org> 
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 <kahchanlow at yahoo.com>

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.
>
>-Pieter
>
>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
>>
>
>
>
>_______________________________________________
>zeromq-dev mailing list
>zeromq-dev at lists.zeromq.org
>http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>


-- 


Sincerely yours, 
Apostolis Xekoukoulotakis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20121112/3d5238a4/attachment.htm>