"Martin P. Hellwig" <[EMAIL PROTECTED]> writes: > and clients make it quite scalable. For example, I'm creating a > xmlrpcserver that returns a randomized cardlist, but I because of > fail-over I needed some form of scalability , my solution was to first > randomize the deck then marshal it and dump the file on a ZFS > partition, giving back the client a ticket number, the client can then > connect with the ticket number to receive the cardlist (read the file > - unmarshal it).
This is a weird approach. Why not let the "ticket" by the (maybe encrypted) PRNG seed that generates the permutation? > While this is overkill for 1 server, I needed multiple because of > fail-over and load-balancing, in this case I have 3 'crypto' boxes > (with hardware crypto engines using OpenBSD) doing only the > randomizing and 4 solaris machines doing the zfs and distribution of > the list. I don't know what good that hardware crypto is doing you, if you're then writing out the shuffled deck to disk in the clear. -- http://mail.python.org/mailman/listinfo/python-list
