From: Gregory Maxwell <gmaxwell@gmail•com>
To: Christian Decker <decker.christian@gmail•com>
Cc: Bitcoin Development <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Useful bitcoin patches...
Date: Fri, 1 Jul 2011 12:23:59 -0400 [thread overview]
Message-ID: <BANLkTimiNOynfvQnncUeiRoZm+CG6njjoA@mail.gmail.com> (raw)
In-Reply-To: <BANLkTi=+jZCANpe8Bmh_7e6KNnQZjF35yA@mail.gmail.com>
On Fri, Jul 1, 2011 at 12:03 PM, Christian Decker
<decker.christian@gmail•com> wrote:
> Some appear to be beneficial to everybody.
> Multithreading the RPC will certainly speed up quite a few services and I
> see no downside in adding it. The same is true for Keep-Alive.
The multithreaded RPC stuff will need very aggressive testing to make
sure it doesn't expose race conditions elsewhere in the code.
E.g. you don't want to lose change from a send because some txn called
getnewaddress concurrently and there was a bug. So far the
multithreaded RPC patches have pretty much only been run by miners...
who have a different rpc profile than everyone else.
(and the MT RPC that I've been using only multhreaded getwork…)
> The Hub mode is good, and I would go a step further and optimize the
> connection logic for all nodes by default.
Gah. No.
The 'hub mode' is not good. We're already low on sockets network wide,
adding a built in DDOS mode flag to bitcoin that makes nodes
aggressively connect to lots of neighbors is a bad idea. People will
ignorantly enable it thinking they are adding resources to the network
when they are really consuming much much more.
I have a big fast node with a higher connection limit and the flood
fixes and I'm currently seeing 596 inbound connections right now. This
suggests the situation is already a lot worse than the rough numbers
using lfnet connection counts suggested.
Miners, concerned with fast block propagation, should manually addnode
each other. We should fix the addnode logic so that it reserve
connection slots for addnoded nodes and tries to keep connecting to
them (or, alternatively, add a peernode flag for that behavior)
currently addnode is oneshot.
There is a lot of room for longer term improvements to the connection
and forwarding logic, and I have a couple interesting ones I'm running
on my nodes, but we don't really have any good way to test and
validate changes, so I'm hesitant to publish them.
next prev parent reply other threads:[~2011-07-01 16:24 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-01 3:23 Jeff Garzik
2011-07-01 16:03 ` Christian Decker
2011-07-01 16:23 ` Gregory Maxwell [this message]
2011-07-01 16:25 ` Matt Corallo
2011-07-01 18:59 ` Luke-Jr
2011-07-10 18:42 ` Luke-Jr
2011-07-10 19:12 ` Matt Corallo
2011-07-10 20:30 ` Luke-Jr
[not found] ` <1310335963.2230.29.camel@Desktop666>
[not found] ` <201107101846.09997.luke@dashjr.org>
2011-07-10 22:58 ` Matt Corallo
2011-08-04 20:29 ` Luke-Jr
2011-08-04 20:42 ` Luke-Jr
2011-08-04 23:43 ` Jeff Garzik
2011-08-05 3:01 ` Luke-Jr
2011-09-03 15:27 ` [Bitcoin-development] Last try: Fixes for 0.4 Luke-Jr
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=BANLkTimiNOynfvQnncUeiRoZm+CG6njjoA@mail.gmail.com \
--to=gmaxwell@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=decker.christian@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox