A critic of Guido's blog on Python's lambda

[Martin P. Hellwig]

Paul Rubin wrote:
> "Martin P. Hellwig" <mhellwig at xs4all.nl> 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