Stop processing messages on full send buffer and dont disconnect.

[TheBlueMatt]

Also decrease default send/receive buffer sizes from 10 to 5 mb
as this patch makes it easy for a node to fill both instead of
only send.

The largest advantage is not having to read from disk or serialize blocks on getblocks requests.

[TheBlueMatt]

I did test downloading from block 143XXX to current tip and didnt see any issues (nor even any warnings about send buffer being full, which makes sense given that this is downloading from one local node to another)

[jgarzik]

Looks like fun stuff to play around with... building now.

Disagree with the minor AddAddress debug change. Once a node is running, these messages are (a) minimal and (b) useful. Better approach is to start separating messages at a much more fine grain, by introducing, e.g. fNetDebug (network-related messages) and fTxDebug (tx/mempool-related messages)

[TheBlueMatt]

Everything short of the last commit is part of #771 and is just here because I had that branch checked out when I wrote this, plus I dont expect this to get merged until 0.7 anyway, so there is no point doing it on master.
And agreed on the more finely controlled Debug messages, but AddAddress gets really annoying when you are reading debug.log right after startup (which, if you have an error, its likely to occur closer to startup anyway) Maybe one printf per AddAddress...

[sipa]

@TheBlueMatt addrman has significantly less address messages (it adds groups of incoming addrs at once).

[TheBlueMatt]

Ah, well Ill go drop that commit from CBlockStore then.

[Diapolo]

The strings explaining -maxreceivebuffer and -maxsendbuffer should be updated to reflect the change of the default size.

[TheBlueMatt]

Oops, good point...fixed.

[Diapolo]

Helping and get helped, right ;).

[gavinandresen]

The "don't disconnect" part of this change worries me.

If an attacker can connect to you 100 times from 100 different IP addresses and then fill up the send buffer on each connection that's bad.

I suppose they could try to fill up your send buffer minus 1 byte now...

[TheBlueMatt]

This patch doesnt change the difficulty of eating 10MB of any node's ram. Also, I dont see much option in the way of disconnecting nodes for eating too much ram in buffers, we may end up just killing nodes behind 24.4k modems. Or atleast I dont trust myself enough to write any kind of such code.

[jgarzik]

ACK

[TheBlueMatt]

Rebased.

[sipa]

What if a node sends you a good new latest best block while the send buffer to that node is full, and then disconnects?

Probably not a real issue, and I certainly likes this approach more than the earlier hack to cut off the 500 block invs earlier when size exceeds the buffer.

[sipa]

ACK

[gavinandresen]

ACK