Unique identifications for peers

[Jason Beyers]

Hi,

I'm trying to implement a load testing tool using SnakeMQ that requires many clients to connect to a single server ("listener").  

I notice from the docs as well as my own testing that a given listener will refuse connections from clients that share an identifier with one that is already connected.  For small #s of clients spawned by the same script, I'm able to keep their identifiers unique and avoid this issue.  However, when I need to start clients on different remote machines without any shared state, uniqueness becomes a big issue.  Is there any way for a client to connect to a listener without an identifier and possibly fetch a unique one from the listener upon connecting?

It appears that the concept of an identifier only exists at the SnakeMQ messaging layer and not the packeting or link layers, but I'm not sure.  Any way I could leverage the lower layers initially to fetch a unique identifier before a client sends something on the messaging layer?

Thanks!

-Jason

[Jason Beyers]

I should also mention that, at least in my case, I would have multiple clients per host, meaning that the system's host/ip would not be unique enough.

Thanks!

-Jason

[David Široký]

Hi Jason!

Each peer (all listeners and connectors) must have a unique identifier because if you send a message it must be clear who is the recipient. In your test case I suggest using module uuid and its function uuid1() which guarantees (almost 100 %) uniqueness among the world (note: maximum identifier length is 50 characters), e.g.:

identifier = "client" + str(uuid.uuid1())

You can use the Packeter layer for some custom initial handshake and after that attach the Messaging but I don't know if it will work while the loop is already running.

David

[Jason Beyers]

One more thing I forgot to mention - I may be using many thousands of clients for a single listener (on high-perf hardware for listener).  I could randomly generate each identifier client-side and take comfort in the fact that if the identifier is long enough, the chances of duplicates would be very slim.  I'll keep that option as a solid backup if there are no better alternatives.

[Jason Beyers]

Thanks David!  I'll try using UUIDs - that'll suit my needs well.