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]<mailto:[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]<mailto:[email protected]> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
