📅 Original date posted:2013-03-23
📝 Original message:On 03/23/2013 11:24 AM, Jeff Garzik wrote:
> On Sat, Mar 23, 2013 at 10:52 AM, Luke-Jr <luke at dashjr.org> wrote:
>> On Saturday, March 23, 2013 10:42:26 AM Randy Willis wrote:
>>> Introducing super-nodes with thousands of connected peers can greatly help
>>> here.
>>
>> UDP is connectionless.
>> I would hope any UDP bitcoin protocol doesn't try to emulate a connection. :/
>
> It depends on the usage. Simply broadcasting a TX or INV to a remote
> peer does not require a connection, clearly... but you probably want
> to signal acceptance of those messages somehow.
>
> But other uses, like subscribing to a broadcast, does require some
> notion of an association.
>
> In the rough draft, a parallel TCP connection with version/verack
> sequence is required, and you may make use of it if a connection is
> needed.
>
> But that is just one approach. A more robust, heavyweight UDP P2P
> might be a hole-punching TCP alternative. It's up to the community
> and results of experimentation.
>
> Bittorrent has evolved a full transfer protocol over UDP, to get
> around firewalls and the like.
>
Bittorrent uses UDP in 2 ways and for different reasons.
The tracker protocol is now UDP because large trackers are under such
enormous strain from short lived HTTP connections (40Gb/s) that there
have been instances of upstream routers becoming overloaded from the
storm of SYN, ACK and FIN messages. UDP helps solve that.
The inter-peer protocol is now UDP because TCP does not play nice in
the context of bufferbloat and Bittorrent needs lots of active TCP
connections to work, exacerbating the problem. In this instance
Bittorrent uses a full userspace TCP stack which just sends w/ UDP.
+1 for experimenting with UDP, we might learn some interesting things.
It's worthwhile to actually speed test UDP v. TCP because the time to
send an INV on an established TCP connection with Nagle disabled may
not be significantly longer than that for sending with UDP.
Also +1 for experimentation with sending a small transaction instead
of an INV, if INVs are not being grouped because we want the fastest
possible network propagation, they are mostly overhead anyway. If
b/w is more important than propagation speed then of course TCP/Nagle
is the way to go.
Thanks,
Caleb
Caleb James DeLisle [ARCHIVE] /
npub138…9dl95
2023-06-07 11:41:09
in reply to nevent1q…mdad
Author Public Key
npub138d0km3t8jujy9duwng26dh79fwuxqhw0xmxjdw2h2t2dgwzwpxsk9dl95Published at
2023-06-07 11:41:09Event JSON
{
"id": "3c29540c62c1f716acf2a437f5e6566d88d52f8c0b8f6ace8d64ebca0bab7958",
"pubkey": "89dafb6e2b3cb92215bc74d0ad36fe2a5dc302ee79b66935caba96a6a1c2704d",
"created_at": 1686138069,
"kind": 1,
"tags": [
[
"e",
"9f3717d2661d30ceb2ea28db676d50e47daabf92c9f58786468587b07e67b8da",
"",
"root"
],
[
"e",
"52ab09d49405c19757582968032ac6a80e59cb8d4b039ea0522f50aeda9be411",
"",
"reply"
],
[
"p",
"b25e10e25d470d9b215521b50da0dfe7a209bec7fedeb53860c3e180ffdc8c11"
]
],
"content": "📅 Original date posted:2013-03-23\n📝 Original message:On 03/23/2013 11:24 AM, Jeff Garzik wrote:\n\u003e On Sat, Mar 23, 2013 at 10:52 AM, Luke-Jr \u003cluke at dashjr.org\u003e wrote:\n\u003e\u003e On Saturday, March 23, 2013 10:42:26 AM Randy Willis wrote:\n\u003e\u003e\u003e Introducing super-nodes with thousands of connected peers can greatly help\n\u003e\u003e\u003e here.\n\u003e\u003e\n\u003e\u003e UDP is connectionless.\n\u003e\u003e I would hope any UDP bitcoin protocol doesn't try to emulate a connection. :/\n\u003e \n\u003e It depends on the usage. Simply broadcasting a TX or INV to a remote\n\u003e peer does not require a connection, clearly... but you probably want\n\u003e to signal acceptance of those messages somehow.\n\u003e \n\u003e But other uses, like subscribing to a broadcast, does require some\n\u003e notion of an association.\n\u003e \n\u003e In the rough draft, a parallel TCP connection with version/verack\n\u003e sequence is required, and you may make use of it if a connection is\n\u003e needed.\n\u003e \n\u003e But that is just one approach. A more robust, heavyweight UDP P2P\n\u003e might be a hole-punching TCP alternative. It's up to the community\n\u003e and results of experimentation.\n\u003e \n\u003e Bittorrent has evolved a full transfer protocol over UDP, to get\n\u003e around firewalls and the like.\n\u003e \n\nBittorrent uses UDP in 2 ways and for different reasons.\n\nThe tracker protocol is now UDP because large trackers are under such\nenormous strain from short lived HTTP connections (40Gb/s) that there\nhave been instances of upstream routers becoming overloaded from the\nstorm of SYN, ACK and FIN messages. UDP helps solve that.\n\nThe inter-peer protocol is now UDP because TCP does not play nice in\nthe context of bufferbloat and Bittorrent needs lots of active TCP\nconnections to work, exacerbating the problem. In this instance\nBittorrent uses a full userspace TCP stack which just sends w/ UDP.\n\n\n+1 for experimenting with UDP, we might learn some interesting things.\n\nIt's worthwhile to actually speed test UDP v. TCP because the time to\nsend an INV on an established TCP connection with Nagle disabled may\nnot be significantly longer than that for sending with UDP.\n\nAlso +1 for experimentation with sending a small transaction instead\nof an INV, if INVs are not being grouped because we want the fastest\npossible network propagation, they are mostly overhead anyway. If\nb/w is more important than propagation speed then of course TCP/Nagle\nis the way to go.\n\nThanks,\nCaleb",
"sig": "f6993f972bb5671ba78955d578617cd920212b7d4e69c45a7105347204bd2f0e7fca4cf0f72f79367b5245c462068e10734abc278cb5a2dad1f38603d7a8a79d"
}