š
Original date posted:2011-08-05
šļø Summary of this message: The number of connections in a network needs serious thought, too many and you fill everyone's connection slots, too few and you don't have a network.
š Original message:On 2011 August 05 Friday, Matt Corallo wrote:
> On Fri, 2011-08-05 at 12:58 +0100, Andy Parkins wrote:
> > I don't really see that "number of connections" is the relevant metric.
>
> Number of connections is something that needs serious thought. Too many
> and you fill everyone's connection slots and no one can make
> connections. Too few and you don't have a network but just a bunch of
> islands which would also cause serious problems.
> If you aren't relaying, each connection takes almost no bandwidth, so
> the question is how many do you need to be considered secure.
I'm arguing that "number of connection slots" isn't the best metric; so that
wouldn't matter. Just keep accepting incoming connections (with some sanity
limit of course) until you've allocated your bandwidth, not your number of
connections.
If I connect to a thousand nodes and never send anything, I'm not using up
very much of their resources. If _they_ want to use up resources by relaying,
then that is their choice, but again they can do that based on bandwidth
calculations rather than connection counts. If I am sending, then that adds
to their bandwidth and gets included in whatever limit they've chosen.
For example: the client could simply maintain an average bandwidth over all
connections. If that average is less than threshold0, then make new outgoing
connections. If that average exceeds threshold1, then stop accepting incoming
connections. If it exceeds threshold2, start dropping established incoming
connections. If it exceeds theshold3, start dropping established outgoing
connections.
The actual rules don't matter so much; I'm just saying bandwidth is a better
metric than connection count. If you limit by connection count, then you'll
just end up filled with non-relaying listeners, since they (in the future)
will be the most commonplace. You'll have no incoming relays, and therefore
nothing to forward, so your bandwidth will be zero, but your connection count
at maximum -- you've locked yourself out.
Andy
--
Dr Andy Parkins
andyparkins at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110805/c74ccaae/attachment.sig>;
Andy Parkins [ARCHIVE] /
npub1nxā¦7wjrv
2023-06-07 02:12:59
in reply to nevent1qā¦m3ka
Author Public Key
npub1nxlvf9mj3jzgue25n5d9y47s3h5hvg0ded9hwpejdxj9mtrs34vs97wjrvPublished at
2023-06-07 02:12:59Event JSON
{
"id": "8137aaa0e4089ce6d6d5bf3f2fb141c5154ca5490575f32ec697a495803f8fa9",
"pubkey": "99bec497728c848e65549d1a5257d08de97621edcb4b77073269a45dac708d59",
"created_at": 1686103979,
"kind": 1,
"tags": [
[
"e",
"f7bac66510d148bc7cd5c36f79897fafe3410a2bc9df45238a65f8429b9407f0",
"",
"root"
],
[
"e",
"88474514199ec65be1582214f0733ce749619830377decf3446688b73aa68967",
"",
"reply"
],
[
"p",
"cd753aa8fbc112e14ffe9fe09d3630f0eff76ca68e376e004b8e77b687adddba"
]
],
"content": "š
Original date posted:2011-08-05\nšļø Summary of this message: The number of connections in a network needs serious thought, too many and you fill everyone's connection slots, too few and you don't have a network.\nš Original message:On 2011 August 05 Friday, Matt Corallo wrote:\n\u003e On Fri, 2011-08-05 at 12:58 +0100, Andy Parkins wrote:\n\u003e \u003e I don't really see that \"number of connections\" is the relevant metric.\n\u003e \n\u003e Number of connections is something that needs serious thought. Too many\n\u003e and you fill everyone's connection slots and no one can make\n\u003e connections. Too few and you don't have a network but just a bunch of\n\u003e islands which would also cause serious problems.\n\u003e If you aren't relaying, each connection takes almost no bandwidth, so\n\u003e the question is how many do you need to be considered secure.\n\nI'm arguing that \"number of connection slots\" isn't the best metric; so that \nwouldn't matter. Just keep accepting incoming connections (with some sanity \nlimit of course) until you've allocated your bandwidth, not your number of \nconnections.\n\nIf I connect to a thousand nodes and never send anything, I'm not using up \nvery much of their resources. If _they_ want to use up resources by relaying, \nthen that is their choice, but again they can do that based on bandwidth \ncalculations rather than connection counts. If I am sending, then that adds \nto their bandwidth and gets included in whatever limit they've chosen.\n\nFor example: the client could simply maintain an average bandwidth over all \nconnections. If that average is less than threshold0, then make new outgoing \nconnections. If that average exceeds threshold1, then stop accepting incoming \nconnections. If it exceeds threshold2, start dropping established incoming \nconnections. If it exceeds theshold3, start dropping established outgoing \nconnections.\n\nThe actual rules don't matter so much; I'm just saying bandwidth is a better \nmetric than connection count. If you limit by connection count, then you'll \njust end up filled with non-relaying listeners, since they (in the future) \nwill be the most commonplace. You'll have no incoming relays, and therefore \nnothing to forward, so your bandwidth will be zero, but your connection count \nat maximum -- you've locked yourself out.\n\n\n\nAndy\n-- \nDr Andy Parkins\nandyparkins at gmail.com\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 198 bytes\nDesc: This is a digitally signed message part.\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110805/c74ccaae/attachment.sig\u003e",
"sig": "9568aa8552d857762a8c147f3b777c08c2db740c02e5e97d3ec388c5e3049d5efbd2cdcc8c67315befb9046ec80fda10d4c6f5bfc79c105f2d4ec5c48a17954c"
}