On Mon, 2005-05-30 at 13:15 -0700, Kevin Baker wrote: > It might be good to make the machine with the token hold > onto it until another machine requests it. This way each > machine on the cluster will broadcast token requests when > it has messages queued for delivery. The machine with the > token can just hand off first come first server.. or give > it to the machine that has been without the token longest > to balance the token load a bit. This should prevent the > token from zippin around in circles for no reason. Token > by request.
What happens if the machine with the token dies? No, the token pass acts as heartbeat and the global lock at the same time. Adding messages to ask for a token is unnecessary- if a machine thinks it's been long enough, it doesn't need to coordinate anything- it just attempts to regenerate the token. If a machine has the token legitimately, it can stop the regeneration- if a machine is dead, the regeneration will come back. Broadcasts might be possible except for the requirement that nodes be possibly very distant from each-other. Besides, broadcasts don't guarantee delivery either. > Under the same delivery concept it might be good to have a > time to wait threshold for the token so that no one > machine can hold onto it for to long. No. Implementation to defeat cheaters is not possible with a global lock. Adding a method to take away the token from a machine without the regeneration step is really bad. It's bad for the reason that pthread_pause() doesn't exist. -- Internet Connection High Quality Web Hosting http://www.internetconnection.net/
