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.
