As I've understood the intended torrent-functionality, it's for downloading files, there files is either downloaded directly from projects download-server (like now), or from other users that shares as torrent. Users themselves decides if they'll want to share or not.

There was also some talk about allowing sharing "internally", example within a company, but disallowing sharing to other users.

BitTorrent should be only an additional (optional and variably configurable) option to existing HTTP and will (should) not replace it in Boinc.

I also have no issue with downloading or uploading larger files. Most people in the US who have internet access are now on DSL or Cable these days. It is simple enough to limit connectivity to the overnight hours if network performance is an issue. My systems would not be able to support Bittorrent style functionality due to security reasons.

While I have DSL, my uplink speed is limited. I don't have a problem with long uploads, and multi-part forms could be used to help isolate problems with communications.

I do have a problem with any type of server initiated communication, as I understand the above bit-torrent discussion. This type of transaction would either not be possible, or allowed, for my machines.

I do have a potential suggestion concerning the size of the initial replication and the current results return method.

My understanding is that each WU returns a check-sum and it's predetermined 10 percent of the result. If the check-sum is invalid, then that WU has to be sent out for recalculation, and the bandwidth used for capturing the 10 percent of the result will be wasted. This can also result in the other WUs spending a long period with a pending status.

My suggestion is for the client to return the check-sum and keep the results until the server indicates what to do with it. If the results are at pending status, then the client will ask the server the status again when it next checks in. If the status is error, then the results will be discarded. If the status is valid, then the server reply needs to specify which 10 percent of the results should be returned. The client can then initiate another transaction which sends the requested 10 percent to the server. This approach would allow the initial replication to be increased to 15, with the first 10 valid check-sums providing the results. The remaining 5 would be discarded. This approach should decrease both the time required to obtain a quorum, and the overall network traffic as results are only sent when the server is ready for them.

@jal2,

Like the checksum-first sending idea, but don't know if that ability is build into BOINC. That's a question for the techs, but think it's not. Don't like the redundancy increase though. If one fails and sending it out to a 'reliable' host, minimises that. Initially WCG uses 5 days return time just to get things going, but expect it to become longer once the sets branch out i.e. the rush to get quorum will be less. The points will follow eventually. That comes with the territory.

@all,

Whether an algorithm can be made to have a diverse distribution is a thought. As mentioned earlier, it substantially complicates the set up and work unit generation which goes into the 'feeder'. That effort is not likely in pools of only 82 work units as a base. WCG is in a discovery phase on this first.