G'day,

Would it be possible to get someone to put together a useful description of the communication processes used by BOINC.

I see many, many user references to the "Deferring communication for ..." messages, and even though you can sometimes figure out that the server is overloaded and that's why the comms failed, when it happens every attempt over 3-4 days (as it regularly does on my system), it just gets bloody frustrating.

It doesn't help when comms to a "reference site" seem to succeed, but then it still stalls the update.

THis is even more important when users like me are trying to change preferences on the website to see what happens - only to grind our teeth/dentures in frustration when the "update" fails and is retried (without success) 20 or 30 times in a row over a 12-hour period. Meanwhile, our CPUs overheat and our love affair with SETI withers and dies... OK, over-exaggeration there... :)

So could someone please take the time to tell technical folks out here exactly what the process is when our client gets work units, sends work units, and connects via a user-initiated update. When do the preferences get downloaded? Do they get downloaded even though a work request (upload or download) fails? How does this work, and how can we help to ensure that we don't overload the server?

I hope other folks might also be interested, and there seems only to be lowest-common-denominator descriptions on the help pages and other sites.

Thanks in advance,
Pete

---

Data is not Information; Information is not Knowledge; Knowledge is not Wisdom.

G'day,

Would it be possible to get someone to put together a useful description of the communication processes used by BOINC.

I see many, many user references to the "Deferring communication for ..." messages, and even though you can sometimes figure out that the server is overloaded and that's why the comms failed, when it happens every attempt over 3-4 days (as it regularly does on my system), it just gets bloody frustrating.
</quote>A communications deferral is requested by both the server and the client on every connection attempt. The server deferral is a fixed value for the type of responese that is set by the project, and the client uses a random exponential backoff for errors. The larger of these two is used as the backoff till the next automatic communications attempt is allowed.<quote>

It doesn't help when comms to a "reference site" seem to succeed, but then it still stalls the update.

</quote>The reference site is a comercial site that was chosen because of its high availability. The client just does a ping. This is done to make certain that there is a network of some sort. If the communications to the project fails, and the communications to the reference site fails as well, a second reference site is attempted (same criteria as the first reference site). If all of these fail, then there is no network available to the client. If any one of these succeed, then there is a network attached to the client, and the project is just down.<quote>

THis is even more important when users like me are trying to change preferences on the website to see what happens - only to grind our teeth/dentures in frustration when the "update" fails and is retried (without success) 20 or 30 times in a row over a 12-hour period. Meanwhile, our CPUs overheat and our love affair with SETI withers and dies... OK, over-exaggeration there... :)
</quote>Every Tuesday, S@H is offline for a few hours. Occasionally every project is offline either scheduled or not. BOINC does not require all projects to be up all of the time - that why a cache is allowed, and also why multiple projects make sense.<quote>

So could someone please take the time to tell technical folks out here exactly what the process is when our client gets work units, sends work units, and connects via a user-initiated update. When do the preferences get downloaded? Do they get downloaded even though a work request (upload or download) fails? How does this work, and how can we help to ensure that we don't overload the server?
</quote>BOINC uses http post and http get to do file transfers. To report work, request work, and update preferences, first a sched_request_*.xml file is written (replace the * with a version of the project URL). Then that file is sent to the server with http post. The server does whatever it needs to do, and the client does an http get and waits for the schedler_response_*.xml file. Based on this response file, the client then gets other files that it needs.<quote>

I hope other folks might also be interested, and there seems only to be lowest-common-denominator descriptions on the help pages and other sites.

Thanks in advance,
Pete

---

BOINC WIKI

G'day John, thank you for the information. I'll have a look at the content of the various xml files in the near future.

I just wanted to let you know that the BOINC WIKI link in your sig doesn't appear to be valid... I've tried a couple times now, and it just gets a 404.

But thanks for the rest of your answers, I really appreciate it!

Cheers,
PCPEte

---

Data is not Information; Information is not Knowledge; Knowledge is not Wisdom.