Although I don't fully agree with “ZMQ UUIDs should not be used as long term identifiers to clients, since they are guaranteed to be unique per *connection*”. But Jakub Witkowski 's reply give me some inspiration. Here is my solution about this problem (the client is untrusted): Because UUID is changed time to time, so if I could update UUID on server side, then UUID can be used as identifier to client. I think I can do this work on heartbeat. Every 30 sec, for example, client send some checking information to server. When server received the message, it can update the UUID to new one ( if the client reconnected ).
From: gonzalo diethelm Date: 2011-12-05 20:55 To: ZeroMQ development list; zebbey Subject: RE: [zeromq-dev] routing adress problem You said that “ZMQ UUIDs should not be used as long term identifiers to clients, since they are guaranteed to be unique per *connection*”. Are you sure about this? UUIDs are supposed to be universally unique (hence their name). -- Gonzalo Diethelm DCV Chile From: [email protected] [mailto:[email protected]] On Behalf Of Jakub Witkowski Sent: Saturday, December 03, 2011 10:50 AM To: zebbey; ZeroMQ development list Subject: Re: [zeromq-dev] routing adress problem On 2011-12-03 10:14, [email protected] wrote: Hi, I'm trying to use Router/Dealer pattern to make a asynchronous C/S network. There is 1 server, and N client. The client send request message to server, and server reply the client asynchronously. I need to attach a OBJECT to each connection. And all request from a connection will to send to the OBJECT. This will take serveral steps: 1) a client connect to the server, and send the account check request. 2) the server check the account, and bind UUID(ZeroMQ generated) to a OBJECT 3) later, the server receive request message, check the UUID, find the OBJECT, pass the message to the OBJECT If the connection between server and client is break, then the mapping information between OBJECT and UUID is missing. But the client known nothing about this. Later the connection is established again, but the UUID is changed, so the server don't known which OBJECT the message should send to. Because the time between connection break and established is too short, so heartbeat cannot detect connection is break. Is there any way to handle this situation? Thank you! Hello, I believe there is a consensus here that ZMQ UUIDs should not be used as long term identifiers to clients, since they are guaranteed to be unique per *connection*. While mitigating this problem will depend on your use case (esp. whether you *trust* your clients enough to use 2.x's durable sockets), the best way to do it seems to be through assigning some higher level, semi-permanent identifier in your business logic layer. Now whenever your client looses it's connection and re-connects, it can present that identifier in the first message, allowing you to update the client-uuid relation in your database. As an example: - An untrusted client is connecting to the server, claiming to be the client X, - The server issues a secure challenge, based on known properties of client X (user name, password hash etc) - The client responds with a generated response, once more based on it's properties, - the server checks that response and if it's correct, issues a time limited token for the client to use during eventual re-connects. If you trust your clients *and* trust your network, you can simplify this a lot using durable sockets. Jakub Witkowski. _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev Declaración de confidencialidad: Este Mensaje esta destinado para el uso de la o las personas o entidades a quien ha sido dirigido y puede contener información reservada y confidencial que no puede ser divulgada, difundida, ni aprovechada en forma alguna. El uso no autorizado de la información contenida en este correo podrá ser sancionado de conformidad con la ley chilena. Si usted ha recibido este correo electrónico por error, le pedimos eliminarlo junto con los archivos adjuntos y avisar inmediatamente al remitente, respondiendo este mensaje. Disclosure: This Message is to be used by the individual, individuals or entities that it is addressed to and may include private and confidential information that may not be disclosed, made public nor used in any way at all. Unauthorized use of the information in this electronic mail message may be subject to the penalties set forth by Chilean law. If you have received this electronic mail message in error, we ask you to destroy the message and its attached file(s) and to immediately notify the sender by answering this message.
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
