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