IIRC the option to return result immediately was created for the boinc alpha project to test WUs, functionality, etc quicker but wasn't meant to be put into "production".

---

IIRC the option to return result immediately was created for the boinc alpha project to test WUs, functionality, etc quicker but wasn't meant to be put into "production".

yeah, but FC is right, if an independent implementation of the client chooses to report right away (as an option or as it's only mode of reporting) then there is not a lot the project can do to stop it.

Agreed...

However, Rosetta said from the beginning that they want good enough hardward to handle the same size user base as seti. So even though Rosetta doesn't have a choice, I doubt it'll have much effect anyway.

---

Agreed...

However, Rosetta said from the beginning that they want good enough hardward to handle the same size user base as seti. So even though Rosetta doesn't have a choice, I doubt it'll have much effect anyway.

Even Seti finds it hard to handle thei userbase :)

---

Team mauisun.org

IIRC the option to return result immediately was created for the boinc alpha project to test WUs, functionality, etc quicker but wasn't meant to be put into "production".

yeah, but FC is right, if an independent implementation of the client chooses to report right away (as an option or as it's only mode of reporting) then there is not a lot the project can do to stop it.

Um, not quite.

If you contact the scheduler, AND IF THEY WISH TO SUPPRESS THIS ACTION, it is doable, because the scheduler will just drop your connection.

The people that repetitively hit the "Update" button were the first to inspire this type of defense.

I hate to say it, but, if you want to alter the design just to suit what amounts to a whim, well, this could be a behavior that will be programmed against. THere is a good discussion of the design issues in the Wiki now, but fundamentally, letting the system work as designed does reduce the total load because the back end parts are writen with the planned default behaveior in mind.

---

yeah, but FC is right, if an independent implementation of the client chooses to report right away (as an option or as it's only mode of reporting) then there is not a lot the project can do to stop it.

Um, not quite.

If you contact the scheduler, AND IF THEY WISH TO SUPPRESS THIS ACTION, it is doable, because the scheduler will just drop your connection.[/quote]

How does it know?

How can it tell the difference between a client that needs to report because the settings say it is within half the connect time of the deadline, and one where the client is using a different set of rules? As I understand it the sceduler does not have access to all your settings info at the point it decides whether to allow or drop the connection.

Repeated updates are easy, all it has to do is to remember your last update and ban repeats that are too close.

Yes, ultimately it is doable, but in practical terms not without a huge amount of complexity that defeats the advantage of having separate steps anyway.

...letting the system work as designed does reduce the total load because the back end parts are writen with the planned default behaveior in mind.

agreed. I wasn't saying people *should* write in different logic, only that (beyond very simple tests) it is hard for the scheduler to detect heretical practices.

R~~