In article <jNyRe.7887$t4.7672@newsfe1-gui.ntli.net>,
Martin 53N 1W  <ml_news@ddnospamddml1dd.co.uk.dd> wrote:

John F Hall wrote:

In article <3n3bh1pclpaeonike8ln9ictfjb4m5uvua@4ax.com>, f/fgeorge  <*> wrote:

<fredclark@consltec.demon.co.uk> wrote:

[...]

(and are crunching). In other cases no downloads have been achieved, so
no crunching. 

This is despite being booted up and running online (ADSL) for several
hours.

Because there are over 100,000 of us with over 400,000 computers ALL
trying to connect AT THE SAME TIME!

[...]

That's because Berkeley seem to have programmed a "Denial of Service"
attack against themselves.  It's clear their "backing off" stategy is
seriously flawed.  I hope they will rethink it.

I wonder if their exponential backoff works only for the initial contact 
with the servers. This would mean that it works well for when the 
servers are off, but it will not work well if congestion or connections 
limits problems drop the connection during later handshaking.

I would expect it to work for any failure, but cannot really say.

Actually having glanced at the code (but not studied it in depth) and
thought more about what was happening on the downloads, it's not clear
that the back-off is happening sensibly.  Could there be a bug?

Do they use one TCP connection for the entire communication? Or must new 
connections be created to complete the transfer process?

As far as I can see there is just one TCP connection.

Or might they just be running out of resource on their backend stuff?

That too :-), but I'm reporting how the BOINC client (4.45) was behaving
at my end.

So, what's wrong?  The main problem seems to be each request backs off
*independently*.  I would have thought that the uploads and downloads
should each be backed off as a *group*. ...

Good idea.

To clarify that, I should have said as two groups, one for uploads, one
for downloads.

-- 
John F Hall