Absolutely correct. Whatever you want to tell the clients, they have to poll for it periodically. The best you can do from the project side is "publish" the information.
From the client side, it has to be able to get the information, and getting the information should not be subject to the same loading problem that you're trying to fix. In other words, you can't publish "the upload server is too busy" using the upload server. The client needs to poll periodically. -- Lynn [email protected] wrote: > Yes, but, the server cannot initiate communications with the client in > almost all cases. Once the problem starts, communications may very well be > impossible from the client. > > jm7 > > [email protected] wrote on 07/14/2009 12:30:14 PM: > >> "Lynn W. Taylor" <[email protected]> >> Sent by: [email protected] >> >> 07/14/2009 12:30 PM >> >> To >> >> Carl Christensen <[email protected]> >> >> cc >> >> [email protected] >> >> Subject >> >> Re: [boinc_dev] Optimizing uploads..... >> >> Carl, >> >> You're right, there are ways (by throwing resources at the problem) to >> handle this server-side. >> >> ... and the reason is that typically, that's all that is possible. >> Someone like Amazon.com can't tell Internet Explorer to slow down. >> >> This isn't a "must" sort of thing -- it's a huge opportunity that rarely >> comes along! >> >> Amazon does not own the client and the server, they only own the server. >> >> BOINC owns both. >> >> I'm reminded of the physics "thought experiment" where you put a >> refrigerator in a sealed room, leave the door open and turn it on. >> >> It's hard to figure out how the room temperature changes if you focus on >> the refrigerator -- but it's easy if you look at the refrigerator and >> room as a system. There is a net flow of energy into the room to run >> the 'fridge. >> >> Same thing here. You can look at the servers and shaping and etc., or >> you can look at the BOINC client/server system as a system, and tune the >> whole system. >> >> -- Lynn >> >> Carl Christensen wrote: >>> there are plenty of good server-side means to handle failed >> uploads without having to fiddle with the BOINC client; I think it >> comes back to a project needing to do some homework and take some >> blame if they vastly underestimated number of uploads, bandwidth etc. >>> for example, on CPDN at our peak when we had huge uploads we were >> able to setup a round-robin DNS system so that the same upload URL >> could go to one of three physical servers. then we used >> mod_backhand in apache for more intelligent load balancing, then >> simply have a bunch of upload URL's in our workunits so if one fails >> it just goes to another one (we had 10 upload servers federated >> around the world at one point). these server-side mechanisms to >> deal with things are much more flexible and sensible than trying to >> cram a "one size fits all" solution in a BOINC client. >>> >>> >>> _______________________________________________ >>> 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. >>> >> _______________________________________________ >> 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. >> > > _______________________________________________ > 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. > _______________________________________________ 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.
