On Fri, 28 May 2010 12:14:44 -0700, you wrote:

>So, based on this scenario... the user sees that MW work is downloaded that he 
>does not want ... so he continually resets the project and can circumvent the 
>project limits?
>
>This is now the fourth possible scenario (though it sounds like the only one 
>tested) proposed ... we still have not come up with a way to prevent this from 
>happening ...
>

Don't point to the wrong problem, user manually resetting project very many
times is an unlikely scenario. While this does in some way generate "ghost-wu",
the most common reason for "ghost-wu" is due to connection-problem. If
scheduling-server gets a clients request for work, and scheduling-server sends
one or more wu's to user, but internet-connection drops-out before client gets
the reply, you've got a "ghost-wu". And let's face it, internet-connection
dropping-out is by no means an unfrequent occorrence, and in most instances
users has no control of this, so it's not something they're doing "wrong"...

The internet-connection doesn't even need to drop completely off, in cases a
scheduling-server doesn't give-back new wu's immediately, but uses some seconds
before sending the reply, it's possible that one of the many jumps on it's way
will time-out the connection, and user has gotten some new ghosts...

Now, while most "ghost-wu" is unaffected by whatever user is doing, there is a
couple other possibilities. One is a proxy-server user is running himself, and
increasing the time-out in this can fix the problem. Wrongly-configured firewall
is another problem, even it's apparently a linux it's still a possbility. Also,
if client somehow can't write the scheduler-reply to disk, chances are you'll
also generate ghosts...

As for "fixing" the problem of "ghost-wu"... Well, personally I don't have a
good solution to stop internet-connection from dropping-out...

-- 
"I make so many mistakes. But then just think of all the mistakes
I don't make, although I might."
_______________________________________________
boinc_dev mailing list
[email protected]
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Reply via email to