On 2011-12-05 17:44, Sean Ochoa wrote: > Just a thought. > > Why not use a normal UUID generating lib? Using zmq (or any lib, really) > other than for what its advertised for can have undesired effects. > > In python I would use stdlib uuid 1-4. > > -- Sean > ZMQ identifiers are nothing more but labels put on a virtual, temporary wire. They are, pretty much, the direct equivalent to a (remote_ip, remote_port) tuple; some information about other end's identity can be inferred from it, but not much. Therefore, there's little need for true, global uniqueness in ZMQ's identifiers; the only constraint they should satisfy is uniqueness during given program run.
On the other hand, standard library UUID generators forus on maximum uniqueness; they often repeatedly query hardware for every single bit of extra information; looking up cpu ID, network MAC addresses and even peeking into DMI for motherboard serial number, then carefully crypto hashing all that information with current wall and system time to make sure the generated blob is as unique as it can possibly be. All that information gathering takes time, sometimes even seconds per UUID. Aside from pure speed, there is one more aspect to ZMQ's uid generator: it needs to be portable. Standard libraries avaliable to different systems vary widely and each next separate piece of code a given library depends creates complexity to those building and using it. Pieter Hintjens <[email protected]> wrote: >> On Mon, Dec 5, 2011 at 1:55 PM, gonzalo diethelm<[email protected]> wrote: >> >>> 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). >> You should not use identities as long-term handles to clients. They >> specifically and only make sense as short-term identifiers for >> connections to a single ROUTER socket, period. >> >> The current use of UUIDs is an internal mechanism, not documented. >> libzmq can change its mind at any stage. >> >> -Pieter >> _______________________________________________ >> 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 Jakub. _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
