[RC5] client versions - AIX

Bruce Wilson bwilson at distributed.net
Thu Oct 3 10:33:33 EDT 2002


| >But without that data the pproxies can't compute correct stats.  I 
| >know that towards the end of rc5-64 I usually have 3 to 4% 
| >difference between the number of blocks my pproxy saw and the number 
| >I was credited for.
| 
| I have two suggestions to fix this type of situation.
| 
|   1) There should be provision in the Keymaster code to send a report 
| back to the submitter that lists the SUBMITTED Block Count not just 
| the CREDITED count (with the rejected due to dupes count being 
| reported).

This is very hard, as dups may be eliminated at the keymaster,
fullproxy, or perproxy level.  Each of those levels would need to be
able to build a reply that could find its way back down the chain to the
client.  Even harder is determining which of several computers using
this email was the one to submit a given workunit.

The alternative, sending an email, isn't a great option either.  This
would make it easy for someone who includes dnetc in a trojan to use us
to spam an unsuspecting victim with dup reports.

|   2) There should be a provision at FLUSH and/or FETCH time to send a 
| list of blocks still in the BUFF-IN queue that can get a response 
| that will list those that WILL get rejected so they can be removed 
| from the BUFF-IN prior to being uselessly crunched. I am willing to 
| have the reply come back as an EMAIL not in real-time - just so it 
| can then be read into the program to fix the BUFF-IN.

Again, this creates a huge workload at the network level, because the
workunits you're holding may be found to be a duplicate at any level.
The keymaster may not have even received the workunit yet, but the
fullproxy knows it will be a duplicate.

| On a separate issue, I would like a provision for returning the 
| BUFF-IN units when shutting down a Client (or if over extended). 
| These returned blocks would go onto a separate "returned" queue on 
| the Keymaster that gets handed out PRIOR to other blocks so they care 
| recycled immediately and are not "Lost" until we recycle though the 
| address space.

Rather than returning the blocks, simply import the buff-in files to
another computer which will continue working.  (dnetc -help for syntax)
If you don't have another computer to work on it, it really isn't a big
deal to us if you delete them.  Bovine found that about 60% of the work
we send out gets sent back on that pass - the rest are lost to a variety
of reasons.  Deleting a few buff-in files isn't going to make a big dent
in our return rate.

We probably won't be adding a "recycle these" feature, because returns
would be so seldom as to be of minimal impact, and because of the
potential for abuse.  For example, "recycling" a given buff-in multiple
times, or submitting your own work for a "recycle" after you have
already submitted them completed for credit, in the hopes of causing
someone else to spend time working on duplications of your work.  We
could certainly build code to prevent some of these scenarios, but that
again calls for more code to manage the process which we'd rather put
into new projects and making the network more efficient.


__
Bruce Wilson <bwilson at distributed.net>
PGP KeyID: 5430B995, http://www.toomuchblue.com/ 

Build a man a fire and he'll be warm for a day.
Set a man on fire, he'll be warm for the rest of his life.

--
To unsubscribe, send 'unsubscribe rc5' to majordomo at lists.distributed.net
rc5-digest subscribers replace rc5 with rc5-digest



More information about the rc5 mailing list