1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <calebdelisle@lavabit.com>) id 1UJWVi-0001xa-Su
for bitcoin-development@lists.sourceforge.net;
Sat, 23 Mar 2013 22:01:58 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of lavabit.com
designates 72.249.41.33 as permitted sender)
client-ip=72.249.41.33; envelope-from=calebdelisle@lavabit.com;
helo=karen.lavabit.com;
Received: from karen.lavabit.com ([72.249.41.33])
by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1UJWVh-0007aR-7n for bitcoin-development@lists.sourceforge.net;
Sat, 23 Mar 2013 22:01:58 +0000
Received: from a.earth.lavabit.com (a.earth.lavabit.com [192.168.111.10])
by karen.lavabit.com (Postfix) with ESMTP id C9A5311B989
for <bitcoin-development@lists.sourceforge.net>;
Sat, 23 Mar 2013 17:01:51 -0500 (CDT)
Received: from 192.168.1.3 (c-174-62-136-247.hsd1.ct.comcast.net
[174.62.136.247]) by lavabit.com with ESMTP id GVNL0JFOMO6T
for <bitcoin-development@lists.sourceforge.net>;
Sat, 23 Mar 2013 17:01:51 -0500
Message-ID: <514E2649.70708@lavabit.com>
Date: Sat, 23 Mar 2013 18:01:45 -0400
From: Caleb James DeLisle <calebdelisle@lavabit.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:17.0) Gecko/20130308 Thunderbird/17.0.4
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <CA+8xBpe9D=poPyJ=soGdN3sovqdmvyGGij6FM8PHYGUB5aUkzQ@mail.gmail.com>
<1364035346.19716.YahooMailNeo@web161601.mail.bf1.yahoo.com>
<201303231452.23042.luke@dashjr.org>
<CA+8xBpfvTQ9pEygPmeSf0guOsECu6uecOG-KB=GVXtPKNo23ZQ@mail.gmail.com>
In-Reply-To: <CA+8xBpfvTQ9pEygPmeSf0guOsECu6uecOG-KB=GVXtPKNo23ZQ@mail.gmail.com>
X-Enigmail-Version: 1.4.6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Spam-Score: -1.2 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [72.249.41.33 listed in list.dnswl.org]
2.9 FSL_HELO_BARE_IP_2 FSL_HELO_BARE_IP_2
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
-0.0 SPF_PASS SPF: sender matches SPF record
-2.5 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1UJWVh-0007aR-7n
Subject: Re: [Bitcoin-development] A bitcoin UDP P2P protocol extension
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Sat, 23 Mar 2013 22:01:59 -0000
On 03/23/2013 11:24 AM, Jeff Garzik wrote:
> On Sat, Mar 23, 2013 at 10:52 AM, Luke-Jr <luke@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
|
