Paul Rubin wrote: > "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?
Because the server that handles the generate request doesn't need to be the same as the one that handles the request to give the client that deck. Even more, the server that handles the request calls the crypto servers to actually do the shuffling. So when the server fails before it has given the client the ticket, it could be possible that a deck is already created but not used, no biggie there. But if the ticket is given to the client, than any other server can serve back that ticket to give the shuffled deck, unless the ZFS dies of course but then again thats why I use ZFS so I can mirror them om 4 different machines in 2 different locations. > >> 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. It's not about access security it's more about the best possible randomness to shuffle the deck. -- mph -- http://mail.python.org/mailman/listinfo/python-list
