Stop processing messages on full send buffer and dont disconnect. #973

1. 
   TheBlueMatt commented at 2:39 am on March 22, 2012: member

   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.

2. 
   TheBlueMatt commented at 2:42 am on March 22, 2012: member

   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)
3. 
   jgarzik commented at 4:03 am on March 22, 2012: contributor

   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)

4. 
   TheBlueMatt commented at 4:38 am on March 22, 2012: member

   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…
5. 
   sipa commented at 4:55 am on March 22, 2012: member

   @TheBlueMatt addrman has significantly less address messages (it adds groups of incoming addrs at once).
6. 
   TheBlueMatt commented at 5:22 am on March 22, 2012: member

   Ah, well Ill go drop that commit from CBlockStore then.
7. 
   Diapolo commented at 3:05 pm on March 22, 2012: none

   The strings explaining -maxreceivebuffer and -maxsendbuffer should be updated to reflect the change of the default size.
8. 
   TheBlueMatt commented at 4:56 pm on March 22, 2012: member

   Oops, good point…fixed.
9. 
   Diapolo commented at 5:26 pm on March 22, 2012: none

   Helping and get helped, right ;).
10. TheBlueMatt closed this on Mar 26, 2012

    ---

11. TheBlueMatt reopened this on Mar 27, 2012

    ---

12. 
    gavinandresen commented at 6:30 pm on April 2, 2012: contributor

    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…

13. 
    TheBlueMatt commented at 8:59 pm on April 2, 2012: member

    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.
14. 
    jgarzik commented at 11:29 pm on May 8, 2012: contributor

    ACK
15. 
    TheBlueMatt commented at 8:48 pm on June 6, 2012: member

    Rebased.
16. 
    sipa commented at 7:00 pm on June 12, 2012: member

    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.

17. 
    sipa commented at 3:27 pm on June 14, 2012: member

    ACK
18. Stop processing messages on full send buffer and dont disconnect.

    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.

    9d6cd04b3b
19. 
    gavinandresen commented at 2:42 pm on June 27, 2012: contributor

    ACK
20. sipa referenced this in commit 6c88568fef on Jun 27, 2012
21. sipa merged this on Jun 27, 2012
22. sipa closed this on Jun 27, 2012

    ---

23. coblee referenced this in commit a402cd6909 on Jul 17, 2012
24. jwrb referenced this in commit 75d3ff7b56 on Sep 17, 2015
25. jwrb referenced this in commit e220d874e4 on Oct 22, 2015
26. jwrb referenced this in commit f63ee425fc on Oct 22, 2015
27. suprnurd referenced this in commit d48fe533d6 on Dec 5, 2017
28. lateminer referenced this in commit 9de90168f9 on Jan 22, 2019
29. DrahtBot locked this on Sep 8, 2021

Contributors
TheBlueMatt jgarzik sipa Diapolo gavinandresen

Milestone
0.7.0