You don't really read and try to understand most of the forum posts, don't you?

It is the complete text of the error message "503 Service Unavailable....."

And again, a 5xx http(s) error is a "server side" error message, send back from the server, in contrast to a 4xx error code, which is a "client side" error code and generated by the http(s) client itself. This is well define http(s)/Internet traffic behavior...

https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

https://httpwg.org/specs/rfc9110.html#status.503


Ralf

Yes TPCBF, HyperComputing is right, the HTTP 4xx status codes are also sent by the server. E.g. the server decides that the client sent a bad request and returns that as an answer to the client.

Did you ever bother to read the links? RFC9110 (which replaced RFC2616) is a pretty good start...

Ralf

Web site&forum on one side and the BOINC facing servers should be (and in the past at IBM, were) completely different setups. One going down (be it underlying database issues, upgrade, maintenance) should not take down the other part...
And yes, now in the 6th month since resuming uploading WUs, this should be fixed by now. Unfortunately, due to the lack of communication, we don't know what is causing the delay in fixing this for good. It seems that at least a couple of times (just check Cyclops' overly optimistic announcement posts), they thought that this was done. But then it is impossible to tell if and how "the tech team" is getting its feedback. It certainly doesn't provide any feedback about what the actual issues are and what they a trying to do to fix it. So that they can get qualified feedback.
Instead, over and over again, people keep riding on non-issues and/or come up with yet new ways to work around those issues FOR THEM, AND THEM ALONE, with some of their remedies making things more likely even worse...
Yes, it does.

Ralf

No, I didn't. This is basic stuff for my daily work, I don't need to look it up anymore.


Thanks for the reference, it says that status codes are sent by the server, and that hasn't changed since HTTP 1.0 in 1996.

First some basics:


Regarding status codes in general:

Note: There are no "request status codes" or "client status codes" in HTTP.

And for the client-side error:


Note also that man HTTP 4xx status codes cannot logically be given by the client:
- HTTP 401 Unauthorized: The server decides who is allowed in.
- HTTP 404 Not Found: How would a client know if a server has a certain site/resource without asking it?

If you still don't believe me, google it. You will find the same info everywhere.

Back to topic:
On my machine, a script checks if there are unfinished transfers every few seconds, no matter if they are stalled. If so, the script calls boinccmd --file_transfer http://www.worldcommunitygrid.org/ <random_transfer_file> retry. If the maximum amount of transfers (default=2) are already in progress, this does nothing except clearing any project back-off timer, and putting a random file next in line to be tried. If there are less than 2 downloads running and there are stalled ones, the retry reactivates one or two of them.

Without the script, I often don't get my WUs in time before the ones I have are done and my CPU is idle. This is mostly because the back-off timers quickly jump to waiting hours after a few failed download attempts. Also, while downloads are stalled the client won't ask for new work. With my script, the downloads are processed slowly but steadily and I never run out of WUs. Being aware that flooding the WCG servers with too many requests is not nice, I analyze the BOINC logs (file_xfer_debug option active) and the client does an average 2.5 requests per minute while downloading WUs, and none otherwise. I think for 32 threads running WUs that's a tolerable number. Around 50% of the requests are successful, meaning that on average each download fails only once before finishing successfully.