[zeromq-dev] routing adress problem

[zebbey at gmail.com]

Thank you for your help.
The problem is solved now. ^_^





From: Jakub Witkowski
Date: 2011-12-03 21:49
To: zebbey; ZeroMQ development list
Subject: Re: [zeromq-dev] routing adress problem
On 2011-12-03 10:14, zebbey at gmail.com 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
zeromq-dev at lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20111203/b769431f/attachment.htm>