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
129
130
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gronager@ceptacle.com>) id 1RgX2w-0003Vl-Ny
for bitcoin-development@lists.sourceforge.net;
Fri, 30 Dec 2011 07:38:34 +0000
X-ACL-Warn:
Received: from backup-server.nordu.net ([193.10.252.66])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1RgX2u-0007oi-D1
for bitcoin-development@lists.sourceforge.net;
Fri, 30 Dec 2011 07:38:34 +0000
Received: from [192.168.0.25] (2508ds5-oebr.0.fullrate.dk [95.166.54.87])
(authenticated bits=0)
by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id pBU7cNLi018235
(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO)
for <bitcoin-development@lists.sourceforge.net>;
Fri, 30 Dec 2011 08:38:25 +0100 (CET)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Apple Message framework v1251.1)
From: =?iso-8859-1?Q?Michael_Gr=F8nager?= <gronager@ceptacle.com>
In-Reply-To: <AB205206-AC96-4A95-B100-E8F4461B08C5@ceptacle.com>
Date: Fri, 30 Dec 2011 08:38:22 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <E986F3D9-1FAF-4BEF-8B16-2BEF3897243D@ceptacle.com>
References: <AB205206-AC96-4A95-B100-E8F4461B08C5@ceptacle.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
X-Mailer: Apple Mail (2.1251.1)
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
X-Headers-End: 1RgX2u-0007oi-D1
Subject: Re: [Bitcoin-development] Trickle in CNode::SendMessages
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: Fri, 30 Dec 2011 07:38:34 -0000
Small correction - if the node is the trickle node it gets all invs, not =
just the special quarter. This means that everything get distributed =
everywhere every 12-15seconds, but a special quarter of the hash space =
is treated earlier, so there is a meaning for vInvWait, but there is =
still a mismatch between comments and code.
Cheers,
M
On 29/12/2011, at 23:05, Michael Gr=F8nager wrote:
> In CNode::SendMessages there is a trickle algorithm. Judging from the =
comments it is supposed to:
>=20
> * at each update round a new (random) trickle node is chosen, with 120 =
nodes and an average round time of 100ms (the sleep) we will have moved =
through roughly all nodes every 12-15 seconds.
> * when a node is the trickle node it will get to send all its pending =
addresses to its corresponding peer.
> * when a node is not trickle node (the rest of the nodes) we send =
transaction-invs, however, only 1/4 of them - the rest is pushed to wait =
for the next round and would eventually get sent.
>=20
> However, the way the 1/4 of the invs are chosen is by:=20
> (inv.getHash() ^ hashSalt) & 3 =3D=3D 0
>=20
> As hashSalt is a constant (static, generated on start up) and as the =
hash of an inv is constant for the inv too, the other 3/4 will never get =
sent and hence it does not make sense to carry them around from round to =
round:
> if (fTrickleWait) vInvWait.push_back(inv);=20
> and:
> pto->vInventoryToSend =3D vInvWait;
>=20
> The hashSalt will be different for each node in the peer-to-peer =
network and hence as long as we have much more than 4 nodes all tx'es =
will be sent around.
>=20
> Ironically, this (wrong?) implementation divides the inv forwarding =
hash space into 4, along the same lines as we discussed last week for =
DHTs...
>=20
> I suggest to either keep the algorithm as is, but remove the redundant =
vInvWait stuff, or to change the algorithm to e.g. push the tx'es into a =
multimap (invHash^hashSalt, invHash) and choose the first 25% in each =
round.=20
>=20
> The last alternative is that I have misunderstood the code... - if so =
please correct me ;)
>=20
> Happy New Year!
>=20
> Michael
>=20
>=20
> =
--------------------------------------------------------------------------=
----
> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a =
complex
> infrastructure or vast IT resources to deliver seamless, secure access =
to
> virtual desktops. With this all-in-one solution, easily deploy virtual=20=
> desktops for less than the cost of PCs and save 60% on VDI =
infrastructure=20
> costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Michael Gronager, PhD
Owner Ceptacle / NDGF Director, NORDUnet A/S
Jens Juels Gade 33
2100 Copenhagen E
Mobile: +45 31 62 14 01
E-mail: gronager@ceptacle.com
|
