Sorry, I should have clarified.
Cheers

For starters, there is not a single server (that much I am VERY sure can be assumed), but various ones. And the data that the Internet facing server(s) are handing to you (the BOINC client) via upload (download for you, the BOINC client) needs to come from somewhere. Those are the database servers "behind the scenes", which are not directly connected to the Internet.
Now when you make a request for new WUs, the web server is asking the database servers to give it files "from the hopper/feeder", a database server where the projects have loaded up the projects prepared WUs. (well, first the client will upload WUs,but that is a different battlefield, but the same basic process, just reversed). That data that is send to you is not located/created on the (BOINC) web servers! And it is this connection, behind the scenes, that is the problem. It is not, regardless what so many people are always pestering about, the Internet facing server(s) that are the (main) issue, but the connection between the database servers(via the "hopper"/"feeder") and the web facing server(s). And because there are multiple of those servers involved, there is another layer, a load balancing proxy server (running the HAproxy software) between the actual database servers and the web server(s). This was confirmed in the only post we ever got since the move directly from a WCG tech (Christian, "cubes", a couple of months ago).

A more detailed (in some aspects) diagram of the process can be found athttps://www.researchgate.net/figure/Internal-...OINC-server_fig1_41472232

Well, that is kind of a different issue. And yes, something in the current setup is not right and need to be fixed, and that is that the BOINC "web" servers (they don't server up a web site per se, they just provide the http(s) protocol for the upload and download to/from the BOINC clients, and that is the part where everyone out there sees the symptoms if there is a fiubar behind the scenes) and the web server(s) that provide the web site (including the "Overview" and "Results" pages) as well as the forum, should be separate and both go down at the same time, unless there is something like the now infamous expired SSL certificate from a few months ago. Even the Overview/Results stuff should physically be on a separate system than the forum. Both have databases behind them, the forum the ones that has all the user profiles/login info as well as all the forum messages. But that one is (should be) more or less standalone. There is however a connection between the before mentioned BOINC servers and the database servers for the Overview/Result pages, in that the later gets its data about the WUs per project/user from the BOINC servers. That is also something that Cyclops eluded to in one of his previous posts. As far as that sync of data goes, the Results database (server(s)) and the BOINC servers should not be able to take each other down either, if the BOINC servers are down, the only effect should be that the Results just don't get updated until the BOINC servers are back up, and there should be no way in hell that any issue with the Results server(s) should bring down the BOINC servers (at least that part seems to be working, most of the time)..
The Results server(s)/database is also what handles both the WCG internal as well as the external stats with it's stats run happening twice a day. So issues with the stats (like back filling the missing stats from June through Sep 28th) should effect those servers aloine, and not have any influence otherwise of operations of the web site and the BOINC servers.
Me neither, but I have been now around DC (distributed computing) for a couple of decades, starting with SETI well before there ever was BOINC, and have dealt with the user facing issues at various projects in the past. The basic process as far as BOINC is concerned is the same, in order to have a unified BOINC client for all the different projects out there. just the implementation details (single server/cluster, real iron/cloud, etc) as well as the actual BOINC applications (the program the the BOINC client starts to process a WU, for any give project, as well as handling the download/upload for).

That whole process is a bit simplified, but should be the general process that is involved here. It is certainly more difficult than what a lot of people in here apparently assume...

And if I got any of the above parts fundamentally wrong (not by minute details), I would welcome any WCG tech to correct me as needed...

Ralf

Ralf,
Thanks. Fills in a lot of blanks for me - even though I am still processing what you presented.

Bruce

And you're making stupid assumptions out of nothing!

There are no problems with connecting to databases back-end. Because download problems occur from file servers that DO NOT use databases at all.
Whereas the main project scheduler actively uses database for generating, distributing, issuing to clients and keeps tracks of issued WUs (all the stuff you show on scheme/pic above). But at the same time, there are no any problems with connecting to it - tasks are generated and issued to clients without any problems (no tasks available is not a technical error/problem).

They arise at the next step, when the client, having received the tasks from scheduler (and necessary queries to DB already DONE at this stage) , tries to download the files necessary for them from the file servers that does not use any database and do not use a two-level (front-end-back end which you were trying to describe) structure. It's just a simple file servers with static (non dynamic/generated) content.

So process which USE database and front-end/back-end 2lvl setup servers - run just fine
And process which DO NOT use database server - have connection and bandwidth issues all the time.

So your statement is completely false!

Thanks to Mad Max for pointing out what I think Ralf might have missed in what I was saying -- the linkage between all the stuff in that useful diagram and the upload and download servers is shared file-store! (Serves me right for not going into a lot more detail in that post...)

As Ralf suggested (but perhaps applied in a slightly different context), I'd be delighted to hear from WCG technical staff if there's something non-[BOINC-]standard in the way their upload and download servers work; until then, I have to assume that WCG/IBM left that part of BOINC well alone!...

Cheers - Al.